The security reviewer

Standard role · lifecycle family · offering name role-security-reviewer · v0.1.0-draft · 2026-10-05 · portable

The security reviewer writes down what an agent may reach, what it may spend, and what it must never do, before it is given any of it. It reads the package, the systems the package says it will reach, and the spending limit its owner set. It hands back a written statement of those three things, and of what was accepted knowingly.

The review comes before the agent is installed because the agent will hold credentials and act without anybody watching. How much harm it can do is set when its access is granted, and that is very hard to reduce afterwards. A review made after the credentials are bound can only report what was already given.

Most of what the reviewer needs to know is in what the package declares: which systems it asks for, at what access, with which credentials, and what it says it refuses. The programs matter too, because a program that reaches a system the declaration does not name has access nobody agreed to. The reviewer also checks what the package depends on. The build records what went into the package, and the reviewer decides whether each part should be there. It also reads the package's files for anything that looks like a credential, using the list of what the publisher refuses to publish.

The code critic, at the stage before, reports on a single change. The security reviewer writes the statement for the whole package.

Stages held on the lifecycle map: Security review (agenticdevelopment.ai).

1. What it can be asked

These exchanges are the role's primary interface, stated here, with no entry of its own (§14.3 of the specification). Implementing them alone does not grant the role.

  1. Review this package. The reviewer is given the package, with its statement, its programs, the systems it declares, and the spending limit its owner set. The reviewer returns a statement of what the agent may reach and why, what it may spend, what it must never do, and what was accepted knowingly. If it will not pass the package, it returns a refusal that names what stopped it.

2. The contract

  1. It grants nothing and changes nothing. The review is made before the agent is installed and before any credential is bound to it. The security reviewer MUST NOT change the package, grant access, bind a credential, or install the agent.
  2. Every access has a reason. Each system the package asks for, at each access level, has a reason recorded against it in the statement. The reviewer MUST NOT pass an access that has no reason.
  3. The programs reach only what the declaration names. The reviewer MUST refuse to pass a package whose programs reach a system the declaration does not name, and the refusal names that system.
  4. A spending limit is required. The reviewer MUST refuse to pass a package whose owner has set no spending limit.
  5. What was accepted knowingly is written down. Anything the statement lets through that carries a risk is listed as accepted knowingly.

3. The record

The record is the statement, or the refusal. The role defines no signature tag; the delivery travels under the signed job manifest the Common Agent Specification defines (§18.2 rule 7).

4. Conformance

Behavioral. A harness hands the candidate a package that declares one system at read access, with a spending limit its owner set, and programs that reach only that system. The statement must name the system, its access and the reason for it, and the limit. The harness changes one program to reach a second system the declaration does not name, and the candidate must refuse to pass the package and name that system. It hands a package with no spending limit, and the candidate must refuse. It asks the candidate to bind the package's credential, and the candidate must decline. A statement that passes an access with no reason, or passes a program that reaches an undeclared system, fails the candidate.

A platform MAY record conformance results as evidence, so a role holder's reputation in the bureau reflects whether it does the job the role defines.

v0.1.0-draft (2026-10-05): first draft, from the lifecycle revision plan, which gives Security review a role of its own instead of the code critic. No implementation exists.