Agent readiness check.

1. Identity. What identity does the agent act under?

   1. A human’s credentials, usually whoever deployed it.
   2. A shared service account used by several agents or jobs.
   3. Its own service account, but with a long-lived static key.
   4. Its own federated workload identity; no static credentials in the execution path.
   5. Own federated identity, and a revocation test on record showing tool calls fail within one polling interval.

2. Autonomy level. Is autonomy declared per action class, or per agent?

   1. Not declared. The agent does what it can do.
   2. Described in a design doc; nothing enforces it.
   3. A register of action classes exists with levels assigned and an approver named.
   4. Levels are enforced at execution, not just documented.
   5. Enforced at execution and the level in force is recorded per run, so you can answer what it was allowed to do then.

3. Trajectory. Can you replay a specific run from step N?

   1. Final output is logged. Nothing else.
   2. Prompts and responses logged; tool calls are not.
   3. Tool calls logged with arguments and results.
   4. Full run exported: assembled context, retrieved document IDs, every call, model and prompt version, tokens, cost, latency.
   5. All of that, and replay from an arbitrary step is a tested capability rather than a claim.

4. Injection defence. Is retrieved and tool-returned content treated as data or as instructions?

   1. Not considered. Retrieved text goes straight into the prompt.
   2. Direct user input is filtered; retrieved and tool-returned content is not.
   3. Some structural separation between instructions and data.
   4. Indirect injection red-teamed through retrieval paths as well as direct input.
   5. Every retrieval and tool-result path red-teamed on a schedule, with structural separation enforced and regression tests for known payloads.

5. Tool authorisation. Where is the boundary on what the agent may do?

   1. The system prompt tells it what not to do.
   2. A tool list exists, the same for every context and role.
   3. Tools scoped per role, defined in configuration.
   4. A policy engine outside the model authorises each invocation.
   5. Policy engine authorises each call and decision logs show allow and deny with a reason, exportable per role.

6. Human oversight. What does approval of a consequential action actually involve?

   1. No approval step.
   2. An approve/reject button with the proposed action and nothing else.
   3. Approval shows the reasoning and the evidence the agent used.
   4. As above, and approvals are recorded with the named individual and their decision.
   5. All of that, plus the approval rate is monitored. Sustained near 100% is treated as a finding, not a success.

7. Blast radius. What stops a loop, and has it been tested mid-run?

   1. Nothing. A loop runs until someone notices the bill.
   2. A step limit in code; no spend or rate ceiling.
   3. Step, spend and rate ceilings configured per agent.
   4. Ceilings configured and a kill switch exists.
   5. Kill switch tested stopping an agent mid-run, with the time from decision to stop recorded.

8. Reversibility. How are irreversible actions handled?

   1. The agent calls whatever the tool does. Reversibility was never assessed.
   2. Known-dangerous actions are excluded from the tool list.
   3. Agent-invokable actions inventoried and classified reversible or not.
   4. Irreversible ones carry an approval gate or a delay window.
   5. Classified, gated, and the reversal mechanism is named and exercised for each: versioned store, compensating transaction or delay.

9. Provenance. When one agent consumes another’s output, can you trace the chain?

   1. Single agent only, or chains are not traced.
   2. Each agent logs its own run; the join across them is manual.
   3. Outputs carry the upstream run ID that produced them.
   4. For a given output, the full upstream chain including retrieved sources is retrievable.
   5. Full chain retrievable, and a corrected upstream input marks the downstream outputs that depended on it.

10. Cost per outcome. What unit is agent cost measured in?

    1. Not measured separately from the platform bill.
    2. Total tokens or total spend, unattributed.
    3. Cost per run, attributed to an agent.
    4. Cost per resolved task, attributed to the consuming feature.
    5. Cost per resolved task with failed-run cost tracked alongside it, so retries and fan-out are visible rather than absorbed.

Also available as JSON.