Approved for production

An approval records that people in a workspace checked an agent against the workspace's own policy and signed off on one exact blueprint version of it. It is not a score. A score tells you how an agent performs. An approval records who decided it was ready for production, against which rules, and on which blueprint version.

Approvals are off unless your deployment turns them on. While they are off, the approval policy and approvals pages and every approval endpoint are not available.

How an approval is bound

Each request is bound to the blueprint version the agent was on when the request was made. Badge identifies that version by its blueprint version ID.

An agent's current version is the version bound to its most recent run. The approval applies only while the agent is still on that version. When the current version changes, the approval is revoked (see What revokes an approval).

Approvals apply to workspace agents only.

What a policy requires

Each workspace has one approval policy. Only the workspace owner can read or change it. Admins can work the approvals queue but cannot see the policy. A setting that is left empty is not checked.

What counts as evidence. Only live runs owned by the workspace count: runs in real-LLM or live-endpoint mode, made by the workspace, on the agent's current blueprint version. Simulated runs never count. Runs made anonymously or by a person before they joined the workspace never count. A suite the agent has never run on its current version counts as not passed. An agent with no blueprint uses its whole run history.

Public agents. When an approval is granted for a public agent, the workspace name is public, on the agent's current approval and on its verification certificate. Setting a policy does not change this. Owners should know it before they approve a public agent.

Previewing a change

Before you save a policy, Badge can preview which standing approvals the change would end. The preview changes nothing. Saving the change then reports how many approvals it revoked or expired, and which agents they belong to.

Two worked policies

A strict policy for a regulated buyer. Use this when the buyer's review requires evidence and two people's sign-off.

• Required suites: the three suites the buyer's risk review names.
• Minimum score: 80.
• Minimum pass^3: 90%.
• Maximum measured cost per run: $0.05.
• SBOM required: on.
• Approver roles: owner and admin.
• Minimum approvers: 2.
• Expiry: 90 days.

With this policy, two different owners or admins must approve, neither of them the person who made the request. The approval lapses after 90 days.

A light policy for an internal tool. Use this when the agent serves your own team and the cost of a wrong call is low.

• Required suites: none.
• Minimum score: 60.
• Pass^k and cost: not set.
• SBOM required: off.
• Approver roles: owner and admin.
• Minimum approvers: 1.
• Expiry: none.

Request an approval

1. Open the agent in its workspace and choose Request approval. Owners, admins and members can request an approval. Viewers cannot.
2. Badge checks the agent against the policy, using the evidence rules above.
3. If every gate passes, the request is stored as a candidate and waits for decisions. It appears in the workspace's approvals queue.
4. If any gate fails, nothing is stored. The request is refused with a 422 response that lists every gate.

A workspace can have only one active request per agent. While a candidate or an approved request exists, a new request returns 409. Let it expire or revoke it first.

What a 422 means

A 422 means the agent does not meet the policy today. The request was refused, not lost to a fault, and it left no record. The body has this shape, with one entry per gate:

{
  "detail": {
    "message": "Approval gates not met.",
    "gates": [
      { "gate": "min_score", "required": 80, "observed": 76, "passed": false },
      { "gate": "require_sbom", "required": true, "observed": false, "passed": false }
    ]
  }
}

Each entry gives the gate id, the required value, the observed value, and whether it passed. Read every entry where passed is false. To get a different result, change the agent or its evidence: run the missing suites on its current version, improve the agent, or add its SBOM. Then request again. Asking again without a change gives the same 422. Only a workspace owner can change the policy.

Who can approve

The approver roles setting decides who may approve. Owners can change it.

• No self-approval. The person who requested an approval cannot approve it, even if their role is an approver role. The attempt is refused with 403.
• Quorum. A request becomes approved when the number of different approvers reaches the minimum. Only approvers who still hold an approver role count. Each person votes once. A second vote returns 409.
• One rejection ends the request. A single reject by an eligible approver ends the request as rejected. A rejection needs a comment. There is no rejection quorum. To try again, request a new approval.
• Architecture check. Approving a request whose blueprint version is no longer the agent's current version is refused with 409. The request is revoked at the same time. Submit a new request. The vote that reaches the quorum also re-checks every gate. If a gate no longer passes, the approval is refused with 422 and the gate list.
• Plan. If the workspace's Team plan has lapsed, approving, rejecting, revoking and editing the policy return 402. The approvals queue can still be viewed.
• Comments. An approve comment is optional.

What revokes an approval

An approved request is revoked, and no longer applies, when any of these happens:

• The agent's current version changes. When the agent is bound to a new blueprint version, or returns to an earlier one, an approval on any other version is revoked with the reason blueprint_changed. The approvers are emailed, and the agent.revoked webhook is sent.
• A tighter policy. When you save a policy, every standing approval is checked against it at once. An approval that no longer passes is revoked with the reason policy_tightened. This includes a policy that needs more approvers than the approval has, or that no longer counts an approver who has left the approver role.
• Manual revocation. Any approver role can revoke an approved request. The revocation needs a reason, which is stored on the request and shown to workspace members. The audit log records the request and the reason code, not the reason text.

An approved request also expires once its expiry period has passed. A shorter expiry in a saved policy ends or shortens approvals that were already granted. Expiry is checked when someone reads or writes approval records, so the public endpoint never returns an expired approval.

A revoked or expired approval does not come back. To approve the agent again, request a new approval against its current version.

What the public sees

Anyone can read the current approval of a public agent. The endpoint is GET /api/v1/agents/{id}/approvals/current. An anonymous reader gets exactly four fields:

• status, which is approved;
• the workspace name;
• decided_at, as a date only (YYYY-MM-DD);
• blueprint_version_id.

Nothing else. The policy, scores, requests, comments and approver names are not public. When there is no current approval, the endpoint returns 404.

Members of the workspace get the full record, with the full decision timestamp, or {"status": "none"} when no approval is current.

On a verification certificate, the run's agent shows the line Approved for production by <workspace> · <date>, with a second line bound to blueprint version <id>. The workspace name is public there too, as stated above. The line appears when the agent has a current approval for the version the run was bound to. After a revocation, or for a run bound to another version, the line is gone.

Webhooks

Subscribe a webhook to agent.approved or agent.revoked in Settings, the same way as the other events.

• agent.approved is sent when a request becomes approved.
• agent.revoked is sent when an approved request is revoked, for a change of current version, a tighter policy, or a manual revocation.

Deliveries go to the webhooks of the workspace owner, and of the person who made the request if they are still a member of the workspace. Each delivery uses the usual envelope, event, timestamp and data, and carries the X-Badge-Signature header. See the REST API reference for the verification recipe.

The data object has these fields: agent_id, agent_name, workspace, request_id, status, blueprint_version_id, decided_at, and approvers. approvers lists the display names of the approvers who approved, and never email addresses. An approver without a display name appears as a short member reference. agent.revoked adds revoked_reason, one of blueprint_changed, policy_tightened or manual.

{
  "event": "agent.revoked",
  "timestamp": "2026-10-18T09:00:00+00:00",
  "data": {
    "agent_id": "00000000-0000-4000-8000-000000000001",
    "agent_name": "Support Agent",
    "workspace": "Acme Corp",
    "request_id": "00000000-0000-4000-8000-000000000002",
    "status": "revoked",
    "blueprint_version_id": "00000000-0000-4000-8000-000000000003",
    "decided_at": "2026-10-16T14:02:11+00:00",
    "approvers": ["Dana Ortiz", "member 0a1b2c3d"],
    "revoked_reason": "blueprint_changed"
  }
}

An agent.approved delivery has the same fields, with "status": "approved" and no revoked_reason.

Audit trail

When the audit log is on, approvals write these entries: approval.requested, approval.vote_recorded, approval.approved, approval.rejected, approval.revoked, approval.expired, and approval.policy_updated. Free-text comments and reasons are never written to the audit log. They stay on the request. When a person's account is erased, the comments and revocation reasons they wrote are cleared.

Related

• Team workspaces: roles and seats.
• Agent SBOM: the SBOM gate.
• Scoring methodology: how the score and pass^k are computed.