Checklist: Agent Readiness

The eight-link chain as a working list, plus the three things that make a boundary enforceable rather than declared.

An agent converts an architecture question into an authority question. Every line below exists because a link with no record is a link with no control.

If more than two links are incomplete, the honest position is that the system is not ready for a tier above 2, whatever its scores say.

A completed checklist is not evidence. The evidence is the record it told you to complete — the templates hold those.

Identity and permission

Registered machine identity, unique per agent, never shared Security Architect
No interactive login on the agent identity Security Architect
Authority boundary expressed in the language of the enforcement point Security Architect
Boundary bound to the agent identity, not to a widely shared role Security Architect
Human-readable boundary generated from the machine-readable one, not maintained separately Architect
Comparison job scheduled: granted permissions against the recorded boundary Security Architect
First comparison actually run by hand, and the differences reviewed Security Architect

Tools and constraints

Tool access is an explicit allow-list, never a deny-list
Adjacent capabilities explicitly recorded as not authorized
Per-action value, scope and counterparty limits set
Aggregate and rate limits set — an agent within per-action limits can still cause aggregate harm
Each authorized action classified for reversibility
Escalation thresholds defined: the conditions that route to a human instead of proceeding

Policy enforcement

Constraints enforced by a policy layer, not by instructions in a prompt
Enforcement mode recorded as enforce or observe — observe mode is not a preventive control
Standing-authority Tier 3–4 agents have at least one preventive control, not only detection
Retrieved and incoming content treated as untrusted input, not as instruction
Behaviour on policy-layer unavailability defined: fail closed

Action and kill-switch

Kill-switch conditions objectively evaluable — no judgement required at trigger time AI Governance Body
Conditions narrow and matched to a specific catastrophic pattern, not general anomaly AI Governance Body
Actions on trigger listed in order: suspend, revoke, alert, preserve state System Owner
Out-of-band stop path exists and does not depend on the agent's own control plane Security Architect
Kill-switch tested, with the date and executor recorded System Owner
Named person authorised to re-enable, who is not the daily operator AI Governance Lead

Verification and audit

Post-action verification method defined
Maximum verification latency set, and shorter than the agent's action cadence
Audit log immutable and feeding the Control Plane comparison
Actions attributable to the agent identity end to end
Boundary divergence alerting live — this is an incident at any tier
Delegation chain recorded for multi-agent systems, with authority re-derived rather than inherited

Ownership

A named human Agent Owner, never a team and never a system
The Agent Owner can suspend the agent without an engineering ticket
Autonomy trajectory recorded, so an increase is a planned change rather than a discovery
Agent Card version bound to the deployment authorization