Templates: Agents and Autonomy

Four records for systems that act rather than advise: the Agent Card, the machine-readable authority boundary, the kill-switch condition record, and the oversight design note that stops “human in the loop” from being a claim.

An agent converts an architecture question into an authority question. The records below exist to make that authority explicit, enforceable and comparable — because a boundary that cannot be compared against what the agent actually did is a prohibition nobody can detect the violation of.

The governance chain, and where each record sits. Identity, permission and tool are carried by the Agent Card; policy is the machine-readable boundary; action carries the kill-switch; verification and audit are runtime commitments recorded at authorization.

[Practice recommendation] Fields are marked All, T2+, T3+ or T4. A Tier 1 record that fills every Tier 4 field is not more rigorous, it is less honest: the fields stop being answered and start being completed. Delete what your tier does not require and keep the record short enough that people read it.

Agent Card

Purpose: The enforceable content of an agent's authority, in one record
Owner: System Owner with Security; the Agent Owner is always a named human
Created at: S3, alongside the ADR
Approval: Gate G3; boundary changes require the same authority as the original authorization
Update: Versioned on every boundary change; history preserved
Retention: Life of agent plus 3 years
Related: ADR, Deployment Authorization Record, Control Matrix, Drift/Alert Record

Download Agent CardDOCX · 13 KB

Field	Required at	What good looks like
Agent name and reference	All	One agent, one identity, one card. Multi-purpose agents need multiple cards or a narrower purpose.
Registered machine identity	All	Unique per agent, never shared, no interactive login. A shared service account makes audit meaningless before anything else goes wrong.
Purpose and scope	All	What this agent is for, in one sentence, and what it is explicitly not for.
Authorized tool list	All	An explicit allow-list. Deny-lists fail open, and for something that acts, failing open is the wrong default.
Explicitly not authorized	T2+	The adjacent capabilities a reader would assume it has. Cheap to write, and it is what makes review possible.
Action boundaries	All	Value limits, counterparty limits, rate limits, scope limits. Aggregate limits as well as per-action ones — an agent within its per-action limit can still cause aggregate harm.
Reversibility per action	T2+	Each authorized action classified. This is what turns D3 from a judgement into an inventory.
Escalation thresholds	All	The conditions that route to a human instead of proceeding.
Kill-switch conditions	T3+	Mandatory at Tier 3–4. See the kill-switch record below.
Delegation chain	T2+ multi-agent	Which agents may invoke which, and whether authority is inherited or re-derived. Inherited authority is how boundaries silently widen.
Verification method and latency ceiling	T3+	How actions are checked after the fact, and the maximum time before that check runs. An audit that runs weekly does not constrain an agent acting hourly.
Agent Owner	All	A named human. Never a team, never a system.

How to fill it. Write the allow-list before the prose. Every field that cannot be expressed as a list or a number will end up unenforceable. When the card is complete, ask one question of it: if this agent did something outside this card tomorrow, which line of which log would show it?

Filled example

Reconciliation-Agent-02. Identity: svc-recon-agent-02, dedicated, no interactive login. Tools: read ledger; read bank statement feed; post correcting journal entry. Not authorized: approve payment; modify chart of accounts; access customer records. Boundaries: single entry ≤ 5,000; aggregate ≤ 50,000 per day; suspense accounts only. Reversibility: journal entries reversible; audit trail and downstream reporting not. Escalation: any entry > 5,000, outside suspense, or unmatched item older than 30 days. Kill-switch: entry attempted outside authorized account range, or aggregate exceeded → suspend, revoke posting permission, alert Agent Owner and AI Governance Lead, preserve state. Verification: daily reconciliation of posted entries against approved boundary, ceiling 24h. Owner: Financial Control Manager. Tier 4.

Plain-text version to copy into your own tooling

AGENT CARD
Agent name / reference:        Version:        Date:
Registered machine identity (unique, no interactive login):
Purpose (one sentence) / explicitly not for:
Authorized tools (allow-list):
Explicitly NOT authorized:
Action boundaries: per-action value / aggregate / rate / counterparty / scope:
Reversibility per authorized action:
Escalation thresholds (route to human):
Kill-switch conditions (T3+):
Delegation chain (which agents may invoke which):
Verification method and maximum latency:
Agent Owner (named human):

Machine-Readable Authority Boundary

Purpose: The boundary in a form a policy engine can evaluate and a comparison can detect drift against
Owner: Security Architect with System Owner
Created at: S3; required at G3 for any agentic system
Approval: Gate G3; changes carry the tier's authorization requirement
Update: Versioned in the policy repository, with dual control at Tier 3–4
Retention: All versions, life of agent plus 3 years
Related: Agent Card, Deployment Authorization Record, IAM configuration

Field	Required at	What good looks like
Representation	T2+ agentic	Whatever your enforcement point already understands. Do not invent a format; the boundary must be evaluated by something, not just stored.
Single source of truth	All	Generate the human-readable version from the machine-readable one. Two representations that can drift apart are worse than one.
Identity binding	All	The boundary attaches to the agent's machine identity, not to a role many things share.
Tool and endpoint permissions	All	Explicit allow-list, including method-level granularity where the tool supports it.
Parameter constraints	T2+	Value ceilings, allowed account or counterparty sets, allowed record scopes.
Rate and aggregate constraints	T2+	Per minute, per day, and in total — expressed where they can be enforced.
Enforcement mode	All	Enforce or observe. An observe-mode boundary at Tier 3–4 is not a preventive control and must not be recorded as one.
Comparison job	T3+	The scheduled comparison of granted permissions against this boundary, and who receives the difference.

How to fill it. The point of this record is detection. Before signing it off, run the comparison once by hand: export what the agent's identity is actually granted, diff it against the boundary, and look at the result. The first run finds something in almost every organization.

Filled example

agent: svc-recon-agent-02
tier: 4
enforcement: enforce
tools:
  - id: ledger.read
  - id: bankfeed.read
  - id: ledger.post_journal
    constraints:
      account_range: ["susp-*"]
      max_value_per_entry: 5000
      max_value_per_day: 50000
      max_entries_per_hour: 40
deny_by_default: true
escalate:
  - condition: value > 5000
  - condition: account not in account_range
  - condition: unmatched_age_days > 30
kill_switch:
  - condition: account not in account_range
    action: [suspend_agent, revoke_post_permission, alert_owner, preserve_state]
verification:
  method: daily_reconciliation_vs_boundary
  max_latency_hours: 24
comparison_job: nightly_iam_diff -> agent_owner, ai_governance_lead

Plain-text version to copy into your own tooling

MACHINE-READABLE AUTHORITY BOUNDARY
Stored in: [policy repository path]        Version:
Bound to identity:
Enforcement mode: [enforce / observe]
Allowed tools and endpoints (allow-list, method level):
Parameter constraints (value, counterparty, scope):
Rate and aggregate constraints:
Escalation conditions:
Kill-switch conditions and actions:
Verification method and max latency:
Comparison job and recipients:

Kill-Switch Condition Record

Purpose: The pre-approved conditions under which automated shutdown is permitted
Owner: System Owner; approved separately at Tier 3–4
Created at: S7, approved at G3
Approval: AI Governance Body at Tier 3–4, separately from the deployment decision
Update: Any change re-enters G3
Retention: Life of system plus 3 years, with every trigger event
Related: Agent Card, Deployment Authorization Record, incident process

Field	Required at	What good looks like
Trigger condition	T3+	Objectively evaluable — no judgement at trigger time. “Anomalous behaviour” is not a condition; “entry attempted outside authorized account range” is.
Narrowness justification	T3+	Why this condition matches a specific catastrophic pattern rather than general anomaly. Broad triggers get disabled after the first false positive.
Actions on trigger	T3+	In order: what is suspended, what is revoked, who is alerted, and what state is preserved for investigation.
Who may re-enable	T3+	Named, and not the person who runs the system day to day.
Out-of-band path	T3+	Whether the stop works when the system's own control path is unhealthy. A stop that depends on the thing it stops is not a stop.
Test schedule and last test	T3+	With the date and the executor. An untested kill-switch is a design, not a control.
Trigger history	T3+	Every activation, with the outcome and whether it was correct.

How to fill it. This is the single principled exception to the framework's default prohibition on automated corrective action at high tiers, and it earns that status only by being narrow, pre-approved and tested. Two questions settle most designs: what exactly must be true, and who turns it back on.

Plain-text version to copy into your own tooling

KILL-SWITCH CONDITION RECORD
System / agent:        Tier:        Approved at G3 on:
Trigger condition (objectively evaluable):
Narrowness justification:
Actions on trigger (suspend / revoke / alert / preserve):
Who may re-enable (named, not the daily operator):
Out-of-band path (works when the control path is unhealthy?):
Test schedule / last tested / by whom:
Trigger history (date, cause, outcome, correct?):

Human Oversight Design Note

Purpose: What the human in the path actually sees, decides and can do — and how you will know it is real
Owner: System Owner with the operational manager who owns the reviewers
Created at: S6, confirmed at G3
Approval: Gate G3 for Tier 2 and above
Update: On any workflow change; workflow changes are system changes
Retention: Life of system plus 3 years
Related: Risk Classification Record (D2), Deployment Authorization Record, Control Matrix

Field	Required at	What good looks like
Who reviews	T2+	The role, the volume they handle, and the time available per decision.
What they see	T2+	The output, the confidence or alternatives, and the evidence behind it. A recommendation with no grounds cannot be reviewed, only accepted.
What they must supply	T2+	Something the system did not: a reason code, a selection between genuinely different options, an input. Clicking approve is not a contribution.
Friction symmetry	T2+	The effort to depart from the recommendation compared to the effort to accept it. Asymmetric friction makes the recommendation the decision.
Time budget	T3+	Realistic seconds per decision, compared against what the review actually requires. If the two do not match, the oversight is nominal.
Override-rate threshold	T2+ where D2 ≤ 2 and D1 ≥ 3	Agreed before deployment, with the action on breach. Agreeing it afterwards is arguing about a number you already know.
Escalation path	T2+	What a reviewer does when they are unsure, and how long that takes.
Training and competence	T3+	What reviewers are told about the system's failure modes.
Degradation plan	T3+	What happens to the review when volume spikes — the condition under which oversight actually fails.

How to fill it. Design the oversight point so that a reviewer who is doing their job produces evidence, and one who is rubber-stamping produces a detectable signature. Override rate, time-per-decision and reason-code diversity all do this. Any of them is better than a policy statement.

Plain-text version to copy into your own tooling

HUMAN OVERSIGHT DESIGN NOTE
System:        Tier:        Date:
Who reviews (role, volume, time per decision):
What they see:
What they must supply that the system did not:
Friction symmetry (effort to depart vs effort to accept):
Time budget vs time required:
Override-rate threshold and action on breach:
Escalation path:
Training on failure modes:
Degradation plan under volume spike: