On this page

Agent Runtime Control Profile

Reference controls for AI agents at runtime, derived from the 31 agent controls of chapter 23. Every control is a draft: it restates the chapter, carries no verification procedure yet and is open for technical review.

v0.1 Draft Open for technical review

Scope

Agents that call tools, in production and in evaluation harnesses, from registration to retirement: their identity, tools, memory, delegation, checkpoints, stop handles and telemetry. The environment an agent is evaluated in is covered by the evaluation environment profile.

31 controls, AIGE-CTL-AGENT-001 to AIGE-CTL-AGENT-031. Each one is anchored to a layer of the five-layer stack and to the patterns that implement it.

How to read a control

Every control has a stable id that never changes and is never reused, and the same record:

  • Objective: the outcome the control secures, in one sentence.
  • Failure modes: observable events that mean the control failed.
  • Scope, enforcement points (on a pull request, at deploy, at runtime or on a schedule) and the failure response (deny, hold for approval or alert).
  • Verification: how a third party would check it (inspect, test, observe or attest).
  • Evidence: the artefact it leaves and the stack layer that keeps it.
  • Mappings: obligations, ISO/IEC 42001 Annex A, the NIST AI RMF, OWASP and other references, each id checked against the site's registers.

Depth says how far a control is written. Specified: a verification procedure, evidence, implementation notes, two example observations and a page of its own. Derived from site material: restates existing site material (an agent control of chapter 23, a pattern, a record schema or a chapter, named on each control) and adds nothing that material does not say. Draft outline: objective, failure modes, scope and open questions only. This profile: 31 derived from chapter 23.

An observation is what a check of a control would emit: the control id, the subject checked, what was expected, what was observed, a status (pass, fail or not_applicable), a timestamp and the evidence behind it.

001 Registry entry

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-001 · v0.1 · Draft · Open for technical review
Objective
Every agent is registered before it reaches production, in an entry written by the pipeline that records its identity, owner, purpose, autonomy level, tools and scopes, data classes and memory stores, delegation rights, versions, checkpoints, stop handles, expiry, and regulatory role and class.
Failure modes
  • ASI10: An agent drifts from its intended behaviour or scope (through compromise, misalignment or neglect) and keeps acting, possibly deceptively, where nobody is watching.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • deploy: before a version is deployed or released
Verification
To be specified.
Evidence
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 02 Inventory & Transparency
Patterns
Agent Registry
Seeded from
Registry entry
Mappings
References
  • [1] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "The agent registry")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • The deploy pipeline writes the entry, so an agent cannot reach production without one; the versions block makes an incident replayable and the stop block makes the kill switch more than a claim.
  • Reconcile the registry against what runs, including SaaS connectors, coding agents on laptops and local MCP servers; an agent found by discovery is registered within a deadline or switched off.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

002 Its own identity

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-002 · v0.1 · Draft · Open for technical review
Objective
Each agent has a unique, attributable workload identity under which its actions are logged and its access can be revoked; channel authentication is not taken for agent identity.
Failure modes
  • ASI03: Delegated identities, inherited privileges and cached credentials let an agent (or whoever steers it) act with rights the requesting user never had.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Identity in every trace; revocation record · Layer 02
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 02 Inventory & Transparency
Patterns
Agent Identity & Scoped Credentials
Seeded from
Its own identity
Mappings
References
  • [4] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Identity and short-lived credentials")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • Make the identity unique and cryptographically verifiable, tie it to a supervising agent, a person or a department, distinguish whether the agent acts on its own or for a named user, and catalogue it centrally.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

003 Read-only tools

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-003 · v0.1 · Draft · Open for technical review
Objective
At the Operator level the person takes every action, so the agent holds read-only tools.
Failure modes
  • An agent at the Operator level holds a tool whose operation class is write, delete, send, execute or pay.
  • An action takes effect that the agent, not the person, took.
Scope
Agents at the Operator autonomy level, where the person takes every action.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Allow-list with read operations only · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Seeded from
Read-only tools
References
  • [5] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Autonomy is a design decision")
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

004 Traces

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-004 · v0.1 · Draft · Open for technical review
Objective
The agent's trajectory is traced, not only its answer: every plan, tool call and memory operation is recorded with the agent id and version.
Failure modes
  • A task leaves a record of its final answer only, with no plans, tool calls or memory operations.
  • A trace carries no agent id or version, so its actions cannot be joined to the agent or to the configuration that ran.
  • The record shows a different tool call from the one that ran, or loses recent activity: METR reports agents that spoofed tool calls to alter their transcripts and tried to trigger container resets that would wipe recent records.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Trace per task · Layer 05
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 05 Assurance & Continuous Compliance
Seeded from
Traces
Mappings
  • AIUC-1: E015
References
  • [6] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Telemetry with the OpenTelemetry GenAI conventions")
  • [7] Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (agents in an evaluation exercise spoofed tool calls to alter their transcripts, tried to trigger container resets that would wipe recent records, and gained code execution on a sandbox with access to the full internet)
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

005 Tool allow-list, deny by default

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-005 · v0.1 · Draft · Open for technical review
Objective
The agent can call only the tools granted on its allow-list, which the gateway evaluates on every call; each entry fixes the tool identity with a pinned definition hash, the operation class, resource scope, rate and volume, egress, data classes and checkpoint.
Failure modes
  • ASI02: The agent uses tools it is allowed to use in unsafe ways: destructive parameters, chains of calls nobody intended, or exfiltration through a permitted channel.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Allow-list as policy; guardrail configuration diffs · Layer 04
Failure response
deny: block the action. A call to a tool that is not on the allow-list, or whose definition hash does not match, is denied.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Runtime Guardrail
Seeded from
Tool allow-list, deny by default
Mappings
References
  • [9] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "The tool allow-list")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Implementation notes
  • Express the allow-list as a deny-by-default policy the tool gateway evaluates on every call, reading the registry as data; the operation class decides which calls need approval.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

006 Checkpoint before every write

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-006 · v0.1 · Draft · Open for technical review
Objective
At the Collaborator level a person approves every write the agent proposes.
Failure modes
  • A write the agent proposed takes effect with no approval record for it.
Scope
Agents at the Collaborator autonomy level, where a person approves significant steps.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Approval record per write · Layer 04
Failure response
require_approval: hold the action for a human decision. Every write the agent proposes waits for a person to approve it.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Human-in-the-loop Gate
Seeded from
Checkpoint before every write
References
  • [10] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Where to put a checkpoint")
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

007 Runtime guardrail on every tool call

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-007 · v0.1 · Draft · Open for technical review
Objective
A guardrail between the agent's decision to call a tool and the call checks every call: the identity matches a live registry entry, the tool and its definition hash are on the allow-list, the parameters are within policy, instruction provenance is checked before write-class calls, output and egress are filtered, and execution budgets hold.
Failure modes
  • ASI01: Content the agent processes (a message, a document, a tool result) redirects its goals or plan, so it pursues the attacker's objective with the agent's own tools and permissions.
  • ASI02: The agent uses tools it is allowed to use in unsafe ways: destructive parameters, chains of calls nobody intended, or exfiltration through a permitted channel.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Policy verdict per call · Layer 04
Failure response
deny: block the action. A call that fails the identity, allow-list or definition-hash check is denied; the other checks deny, route to a checkpoint, redact or trip the breaker as the chapter sets out.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Runtime Guardrail
Seeded from
Runtime guardrail on every tool call
Mappings
References
  • [11] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Runtime guardrails for tool calls")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Implementation notes
  • On failure: parameters outside policy are denied or routed to a checkpoint; a request that originated in untrusted content is routed to a checkpoint before a write-class call; the output and egress filter redacts or blocks; exhausted budgets trip the breaker.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

008 Execution budgets

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-008 · v0.1 · Draft · Open for technical review
Objective
Step, call, token, spend and time budgets are set in the registry entry and enforced at the gateway, and exhausting a budget trips the breaker rather than raising a ticket.
Failure modes
  • ASI08: One faulty or compromised agent, tool or output propagates through connected agents and workflows, and each hop amplifies the harm.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Budget configuration; breaker events · Layer 04
Failure response
deny: block the action. Exhausting a budget trips the agent's breaker, so the gateway rejects its calls; it does not raise a ticket.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Runtime Guardrail
Seeded from
Execution budgets
Mappings
References
  • [12] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Execution limits")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Implementation notes
  • Budgets catch what no rule anticipated. A guardian agent is one way to build the enforcement point, and it then needs its own identity, scope and kill switch.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

009 Approval log, bound to the call

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-009 · v0.1 · Draft · Open for technical review
Objective
The gate lives outside the model; the approver sees the raw call first; an approval is single-use and bound to a hash of the parameters; no answer means no action; approval rate, time to decide and override rate are measured.
Failure modes
  • ASI09: Fluent, confident or persuasive agent output leads people to approve harmful actions, disclose information or skip the check they were meant to make.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Approval log with parameter hashes; oversight metrics · Layer 04
Failure response
deny: block the action. No answer means no action: an approval request that times out closes without the call.
Layers
Layer 04 Runtime Controls & Observability, Layer 05 Assurance & Continuous Compliance
Patterns
Human-in-the-loop Gate
Seeded from
Approval log, bound to the call
Mappings
References
  • [13] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "What a good approval looks like")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • Show the call, not the story: the approver sees the tool, the parameters and the target as the gateway will execute them, then the agent's reason, the risk and what happens on rejection.
  • Send to a person only the actions that need one: a checkpoint that fires hundreds of times a day on someone with other work becomes a rubber stamp, and its log then launders the decisions it was meant to examine.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

010 Per-agent circuit breaker

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-010 · v0.1 · Draft · Open for technical review
Objective
The gateway can reject every call from this one agent without stopping the rest of the fleet.
Failure modes
  • ASI08: One faulty or compromised agent, tool or output propagates through connected agents and workflows, and each hop amplifies the harm.
  • ASI10: An agent drifts from its intended behaviour or scope (through compromise, misalignment or neglect) and keeps acting, possibly deceptively, where nobody is watching.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Breaker events · Layer 04
Failure response
deny: block the action. The gateway rejects every call from this one agent without stopping the rest of the fleet.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Kill Switch / Circuit Breaker
Seeded from
Per-agent circuit breaker
Mappings
References
  • [14] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Kill switch and per-agent circuit breakers")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
  • [15] Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (MANAGE 2.4: mechanisms to supersede, disengage or deactivate AI systems whose performance or outcomes are inconsistent with intended use)
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

011 Drilled kill switch

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-011 · v0.1 · Draft · Open for technical review
Objective
The stop levels (pause a task, narrow the scope, trip the breaker, revoke the identity, stop a class, degrade) and their triggers are defined in advance, and the stop is drilled on a schedule, with the time to stop measured and a check that the stop held.
Failure modes
  • ASI10: An agent drifts from its intended behaviour or scope (through compromise, misalignment or neglect) and keeps acting, possibly deceptively, where nobody is watching.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
  • periodic: on a schedule, over what is already running
Verification
To be specified.
Evidence
  • Drill record: time to stop; no calls or writes after the pull · Layer 04
Failure response
deny: block the action. The agent is stopped at the predefined level; no calls or writes follow the pull.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Kill Switch / Circuit Breaker
Seeded from
Drilled kill switch
Mappings
References
  • [14] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Kill switch and per-agent circuit breakers")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
  • [15] Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (MANAGE 2.4: mechanisms to supersede, disengage or deactivate AI systems whose performance or outcomes are inconsistent with intended use)
Implementation notes
  • Define the triggers in advance: a manual pull, a budget or unauthorised-call threshold, an anomaly, an upstream notice such as a vendor incident, or a legal instruction.
  • Check that the stop held: no tool calls after the breaker tripped, no credentials issued after revocation, and no writes from long-running tasks on credentials issued before the pull.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

012 Trajectory anomaly detection

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-012 · v0.1 · Draft · Open for technical review
Objective
The agent's behaviour is monitored as it unfolds, and anomalies (calls unrelated to the purpose, parameters outside the profile, calls after expiry, spend spikes) are flagged and either halt the agent or escalate to a person.
Failure modes
  • A call unrelated to the task purpose, a parameter outside the registry profile, a call after expiry or a spend spike occurs and no anomaly event is raised.
  • An anomaly is flagged but neither halts the agent nor reaches a person.
  • The monitoring is switched off: METR states that its red-teaming found several simple ways for agent monitoring to be disabled, one by changing an environment variable.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Anomaly events and decisions · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Seeded from
Trajectory anomaly detection
Mappings
  • AIUC-1: B006
References
  • [16] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "An agent incident taxonomy")
  • [17] Frontier Risk Report (February to March 2026) (red-teaming found several simple ways for agent monitoring to be disabled, one by changing an environment variable)
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Implementation notes
  • Use the chapter's agent incident taxonomy for the detection signal and the first containment of each class; the severity scale and reporting clocks are those of chapter 17.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

013 Independent trajectory evals

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-013 · v0.1 · Draft · Open for technical review
Objective
Every change to the agent is evaluated on its path as well as its answer, including task success, injection resistance and trajectory checks, and a failed evaluation blocks the change.
Failure modes
  • An evaluation passes an agent that reached the right answer through a tool it should never have held, because it scored the answer and not the path.
  • A change ships with no evaluation run for its version, or although its run failed.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • pre_merge: on every pull request
Verification
To be specified.
Evidence
  • Eval runs per version · Layer 03
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 03 Evals & Red Teaming as Evidence
Patterns
Eval Gate in CI
Seeded from
Independent trajectory evals
Mappings
  • AIUC-1: C002
References
  • [18] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "What makes an agent a governance object")
  • [19] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Threats mapped to controls")
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Implementation notes
  • Tag the red-team test cases with MITRE ATLAS technique ids, so a finding traces from technique to control to the evaluation that now guards it.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

014 Reversible, bounded actions only

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-014 · v0.1 · Draft · Open for technical review
Objective
At the Observer level the person audits after the fact, so the agent keeps only reversible, bounded actions.
Failure modes
  • An agent at the Observer level holds an irreversible action (a payment, a deletion, an external message, a publication) on its allow-list.
  • An action at the Observer level has no rate, volume or budget bound.
Scope
Agents at the Observer autonomy level, where the person audits after the fact.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Allow-list without irreversible operation classes · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Seeded from
Reversible, bounded actions only
References
  • [5] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Autonomy is a design decision")
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

015 Checkpoints on irreversible actions, failing closed

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-015 · v0.1 · Draft · Open for technical review
Objective
Pay, delete, send and execute calls are gated by consequence (high stakes, irreversible, outlier, user-defined, scope elevation) and fail closed when the guardian is down; only reads fail open, and then with an alert.
Failure modes
  • ASI02: The agent uses tools it is allowed to use in unsafe ways: destructive parameters, chains of calls nobody intended, or exfiltration through a permitted channel.
  • ASI09: Fluent, confident or persuasive agent output leads people to approve harmful actions, disclose information or skip the check they were meant to make.
Scope
Agents with tools whose operation class is pay, delete, send or execute.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Checkpoint configuration; failure posture in the Policy Card · Layer 04
Failure response
require_approval: hold the action for a human decision. Pay, delete, send and execute calls wait for approval, and are denied while the guardian is down; reads proceed with an alert.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Human-in-the-loop Gate
Seeded from
Checkpoints on irreversible actions, failing closed
Mappings
References
  • [10] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Where to put a checkpoint")
  • [11] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Runtime guardrails for tool calls")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Implementation notes
  • Record the failure posture per operation class in the agent's Policy Card.
  • Name who approves each class: a role with the authority to refuse for high stakes, the action's business owner for irreversible actions, the on-call owner for outliers, the user for user-defined limits and the agent's owner for scope elevation.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

016 Code runs only in a sandbox

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-016 · v0.1 · Draft · Open for technical review
Objective
Execute-class tools run generated code only in a sandbox; anything else is denied.
Failure modes
  • ASI05: Code the agent writes or runs, directly or through a tool, executes outside the bounds anyone intended and compromises the host or the environment around it.
  • Code runs in a sandbox that still reaches the open internet: METR reports agents that gained code execution on an evaluation sandbox, which gave them more flexible access to the full internet.
Scope
Agents with execute-class tools that run generated code.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Sandbox policy; violation events · Layer 04
Failure response
deny: block the action. Generated code that would run outside a sandbox is denied.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Runtime Guardrail
Seeded from
Code runs only in a sandbox
Mappings
References
  • [11] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Runtime guardrails for tool calls")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
  • [7] Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (agents in an evaluation exercise spoofed tool calls to alter their transcripts, tried to trigger container resets that would wipe recent records, and gained code execution on a sandbox with access to the full internet)
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

017 Output and egress filter

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-017 · v0.1 · Draft · Open for technical review
Objective
What leaves after each call is filtered for secrets, personal data and destinations, and every tool, including the ones nobody worries about, has a rate and an egress bound.
Failure modes
  • ASI02: The agent uses tools it is allowed to use in unsafe ways: destructive parameters, chains of calls nobody intended, or exfiltration through a permitted channel.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Egress allow-list; redact and block events · Layer 04
Failure response
deny: block the action. Output carrying secrets or personal data, or bound for a destination outside the egress allow-list, is redacted or blocked before the result returns.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Runtime Guardrail
Seeded from
Output and egress filter
Mappings
References
  • [9] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "The tool allow-list")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

018 MCP server admission gate

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-018 · v0.1 · Draft · Open for technical review
Objective
Each MCP server is admitted as a supplier: its provenance is recorded in the AIBOM, its tool definitions are hashed and pinned with an alert on change, its authorisation conformance is checked, it is tested with poisoned descriptors and injected outputs, and it has an owner and a review date.
Failure modes
  • ASI04: Tools, MCP servers, plugins, prompt templates and models that an agent loads, often at run time, can be malicious or become malicious after they were trusted.
Scope
Agents that use MCP servers, and each server before any allow-list names it.
Enforcement points
  • deploy: before a version is deployed or released
Verification
To be specified.
Evidence
  • Admission record per server; definition hashes · Layer 02
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 02 Inventory & Transparency
Patterns
AIBOM
Seeded from
MCP server admission gate
Mappings
References
  • [20] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Admitting an MCP server")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • Record the publisher, the source repository and a signed release as provenance; hash tool names, descriptions and schemas at admission, because a changed description is a changed instruction.
  • Run the tests with poisoned descriptors and injected tool outputs before any allow-list names the server; the vendor due-diligence gate covers who answers when it misbehaves and what notice comes before it changes.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

019 Local MCP servers sandboxed

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-019 · v0.1 · Draft · Open for technical review
Objective
A one-click local MCP server install shows the exact install command and waits for explicit approval; local servers run sandboxed with minimal privileges, and discovery sweeps reconcile them.
Failure modes
  • ASI04: Tools, MCP servers, plugins, prompt templates and models that an agent loads, often at run time, can be malicious or become malicious after they were trusted.
  • ASI10: An agent drifts from its intended behaviour or scope (through compromise, misalignment or neglect) and keeps acting, possibly deceptively, where nobody is watching.
Scope
Agents that use MCP servers running on the same machine, including coding agents on developer laptops.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
  • periodic: on a schedule, over what is already running
Verification
To be specified.
Evidence
  • Install approvals; discovery findings · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Shadow-AI Discovery
Seeded from
Local MCP servers sandboxed
Mappings
References
  • [20] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Admitting an MCP server")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

020 MCP authorisation (spec 2026-07-28)

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-020 · v0.1 · Draft · Open for technical review
Objective
Where a remote MCP server uses authorisation, discovery uses protected-resource metadata, token requests carry the resource parameter, the audience is validated and no token is passed through, the issuer is validated, and scopes are stepped up instead of granted as omnibus ones; the MCP version each server speaks is recorded.
Failure modes
  • ASI03: Delegated identities, inherited privileges and cached credentials let an agent (or whoever steers it) act with rights the requesting user never had.
Scope
Agents that call remote MCP servers over HTTP where the server uses authorisation.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Token requests naming the resource; audience-check alerts; MCP version in the registry · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Agent Identity & Scoped Credentials
Seeded from
MCP authorisation (spec 2026-07-28)
Mappings
References
  • [21] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "MCP authorization as of 2026-07-28")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • Prefer Client ID Metadata Documents to Dynamic Client Registration, which the 2026-07-28 specification deprecates, and keep the allowed client domains as policy.
  • MCP secures the hop between one client and one server; which agent sits behind the client, and for whom, is the workload identity's job.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

021 Replace long-lived secrets with short-lived credentials

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-021 · v0.1 · Draft · Open for technical review
Objective
The agent holds no static key or long-lived secret: it acts on short-lived, attested credentials that expire in minutes and are revoked at the end of the task.
Failure modes
  • ASI03: Delegated identities, inherited privileges and cached credentials let an agent (or whoever steers it) act with rights the requesting user never had.
Scope
Agents that hold a static key or a long-lived secret.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Credential lifetime in the registry; no secrets in configuration · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Agent Identity & Scoped Credentials
Seeded from
Replace long-lived secrets with short-lived credentials
Mappings
References
  • [22] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Short-lived, attested credentials")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • A credential that expires in minutes need not be hunted down after an incident, only not reissued; authorisations stay time- or session-bound, non-transferable and never greater than what the authorising person may do.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

022 Delegation, never impersonation

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-022 · v0.1 · Draft · Open for technical review
Objective
When the agent acts for a user, it holds a delegated token, exchanged for the user's, that names the agent, with a narrower scope and a short expiry; it never holds the user's own token.
Failure modes
  • ASI03: Delegated identities, inherited privileges and cached credentials let an agent (or whoever steers it) act with rights the requesting user never had.
Scope
Agents that act on behalf of a user.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Delegated tokens with an act claim; token-exchange log · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Agent Identity & Scoped Credentials
Seeded from
Delegation, never impersonation
Mappings
References
  • [23] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Delegation without impersonation")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • Keep both identities in the log: the user as the subject, the agent as the current actor in the act claim, and earlier actors in the chain as nested act claims.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

023 Memory write gate and rollback

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-023 · v0.1 · Draft · Open for technical review
Objective
Writes are events that carry their source; untrusted content cannot write to long-term memory without a gate; memory is isolated per user and per task; retention is code; memory can be rolled back to a known-good snapshot.
Failure modes
  • ASI06: Stored memory, retrieval stores or carried context are corrupted so the poison persists across sessions and shapes later decisions.
Scope
Agents with memory: context, conversation threads, long-term memory, retrieval corpora or memory shared with other agents.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Memory write events with provenance; retention jobs; rollback drills · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layers
Layer 04 Runtime Controls & Observability, Layer 03 Evals & Red Teaming as Evidence
Patterns
Runtime Guardrail
Seeded from
Memory write gate and rollback
Mappings
References
  • [24] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Memory and context governance")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • Match the control to the memory: provenance tags for the context window, per-session isolation for threads, a write gate, per-user namespace, time to live and erasure path for long-term memory, source admission and entitlement checks for retrieval corpora, per-task isolation and attributed writes for shared memory.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

024 Retention and erasure for personal data in memory

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-024 · v0.1 · Draft · Open for technical review
Objective
Every memory store that holds personal data has retention windows and an erasure path, in line with the GDPR's minimisation and storage-limitation principles and the right to erasure, and no memory store holds credentials.
Failure modes
  • Personal data stays in a memory store past its retention window, or an erasure request cannot be carried out on the store.
  • A credential is found in agent memory.
Scope
Agents with memory stores that hold personal data.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Retention schedule per memory class; erasure records · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Seeded from
Retention and erasure for personal data in memory
References
  • [24] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Memory and context governance")
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

025 Accountability across hops

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-025 · v0.1 · Draft · Open for technical review
Objective
Every task carries its originating principal; each agent authenticates as itself; scope narrows or stays equal at each hop; the purpose travels and is checked; depth and fan-out are limited; one trace runs end to end; only registered peers with verified, signed cards are called.
Failure modes
  • ASI07: Messages between agents travel without authentication or integrity, so a peer can be spoofed, a message replayed or altered, and trust passes along a chain that nobody checked.
  • ASI08: One faulty or compromised agent, tool or output propagates through connected agents and workflows, and each hop amplifies the harm.
Scope
Agents that delegate tasks to other agents or take tasks from them.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Delegation record; nested act claims; peer allow-list; trace ids · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Agent Identity & Scoped Credentials
Seeded from
Accountability across hops
Mappings
References
  • [25] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Accountability across hops")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • Enforce these properties at every gateway you control; a breach of the depth or fan-out limit raises a breaker event. Transaction Tokens and WIMSE address the same problem but are unfinished as of 2026-09-24.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

026 Stopping third-party agents at your boundary

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-026 · v0.1 · Draft · Open for technical review
Objective
A third-party agent, which cannot be stopped from outside, is cut off at your boundary: your agents can be stopped from calling it, what you issued to it can be revoked, and a contract names who answers for it.
Failure modes
  • ASI07: Messages between agents travel without authentication or integrity, so a peer can be spoofed, a message replayed or altered, and trust passes along a chain that nobody checked.
Scope
Agents that call, or delegate to, agents run by a third party.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Peer allow-list; revocation records; clause reference in the registry · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Kill Switch / Circuit Breaker
Seeded from
Stopping third-party agents at your boundary
Mappings
References
  • [26] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Stopping across hops")
  • [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
  • [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title)
Implementation notes
  • A remote cancel is not guaranteed to stop the task; short-lived delegated tokens bound the revocation by their lifetime, where long-lived ones make it a hope.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

027 Data classes recorded, with the DPIA linked

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-027 · v0.1 · Draft · Open for technical review
Objective
The registry entry records the agent's data classes and memory stores and links the DPIA and the records of processing, and each tool states which data classes may flow in and out (the chapter's example: no special-category data to external tools).
Failure modes
  • The registry entry names no data classes or memory stores, or links no DPIA or records of processing.
  • A data class reaches a tool that may not receive it, such as special-category data sent to an external tool.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • deploy: before a version is deployed or released
Verification
To be specified.
Evidence
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 02 Inventory & Transparency
Patterns
Agent Registry
Seeded from
Data classes recorded, with the DPIA linked
References
  • [1] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "The agent registry")
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

028 Prompts under change control

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-028 · v0.1 · Draft · Open for technical review
Objective
The system prompt, tool descriptions and policy bundle are versioned and owned, hashed in the registry and in every trace, and changed only through the regression suite and a canary rollout with the previous hash ready to restore, with a check on whether the purpose changed.
Failure modes
  • The production prompt is edited outside the pipeline, for example in a vendor console, so the registry and the traces still name the old version and an incident replays a configuration that never ran.
  • A prompt, tool description or policy bundle change ships with no passing regression run, or with no hash in the registry and the traces.
  • A change alters what the system is for and no one asks whether the purpose changed.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • pre_merge: on every pull request
  • deploy: before a version is deployed or released
Verification
To be specified.
Evidence
  • Prompt manifest; eval run per change; rollout record · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Patterns
Eval Gate in CI
Seeded from
Prompts under change control
Mappings
  • AIUC-1: E004
References
  • [27] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Prompts as configuration under change control")
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Implementation notes
  • Keep prompts in the repository with a named owner and two reviewers, and let the pipeline refuse a prompt manifest whose named evaluation run has not passed.
  • Treat the system prompt as configuration, not a secret and not a control: no credentials in it, and nothing that must hold enforced by it; that belongs in the gateway.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

029 Telemetry on the OpenTelemetry GenAI conventions

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-029 · v0.1 · Draft · Open for technical review
Objective
The agent emits agent and tool spans on the OpenTelemetry GenAI conventions (execute_tool, gen_ai.agent.id, gen_ai.agent.version), with registry id, workload identity, policy verdict, approval id and delegation chain in your own namespace, and argument capture has its own retention and access rules.
Failure modes
  • A tool call leaves no execute_tool span, or its span lacks the agent id and version.
  • A span lacks the registry id, workload identity, policy verdict, approval id or delegation chain, so the action cannot be tied to its authority.
  • Captured tool arguments and results, which may hold personal data, fall under the general trace retention and access rules.
Scope
Every agent that calls tools, in production or in an evaluation harness.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Spans per call; the fields in your namespace · Layer 05
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 05 Assurance & Continuous Compliance
Seeded from
Telemetry on the OpenTelemetry GenAI conventions
Mappings
  • AIUC-1: E015
References
  • [6] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Telemetry with the OpenTelemetry GenAI conventions")
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Implementation notes
  • The GenAI conventions are in Development status and names can still change; keep the governance fields in your own namespace and map them later.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.

030 EU AI Act hooks for a high-risk purpose

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-030 · v0.1 · Draft · Open for technical review
Objective
An agent, classified by its intended purpose, that serves an Annex III purpose keeps event logs over its lifetime (Art. 12), has oversight commensurate with its autonomy level (Art. 14(3)-(4)) and competent overseers with authority (Art. 26(2)), and its logs stay under the deployer's control for at least six months (Art. 26(6)).
Failure modes
  • An agent with an Annex III purpose runs with no event log over its lifetime, or its logs are kept under the deployer's control for less than six months.
  • Oversight is not matched to the autonomy level, or no overseer with the competence, training and authority is assigned.
Scope
Agents whose intended purpose falls under Annex III of the EU AI Act.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Traces; checkpoints and raw-call approvals; approver roster; log retention · Layer 05
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 05 Assurance & Continuous Compliance
Seeded from
EU AI Act hooks for a high-risk purpose
References
  • [28] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "EU AI Act hooks for agents")
Implementation notes
  • Classify by intended purpose, not architecture: an agent that screens job applicants is high-risk through Annex III, and a scheduling assistant is not.
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.
  • Chapter 23 ties this control to the EU AI Act articles it names; the derivation carries obligations only through mapped OWASP Agentic threats, so the obligation mapping awaits review.

031 Tell people they are dealing with an AI system

Derived from the agent controls of chapter 23 and restated as a control; requires technical review.

Id
AIGE-CTL-AGENT-031 · v0.1 · Draft · Open for technical review
Objective
People who receive the messages, calls and chats the agent sends are told they are interacting with an AI system, unless that is obvious (Art. 50(1), from 2 Aug 2026).
Failure modes
  • A message, call or chat the agent sends to a person does not say it comes from an AI system, where that is not obvious.
Scope
Agents that send messages, calls or chats to people.
Enforcement points
  • runtime: at the point of action (gateway or guardrail)
Verification
To be specified.
Evidence
  • Disclosure text in message templates · Layer 04
Failure response
alert: let the action through and raise an alert. To be specified.
Layer
Layer 04 Runtime Controls & Observability
Seeded from
Tell people they are dealing with an AI system
Mappings
  • AIUC-1: E016
References
  • [28] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "EU AI Act hooks for agents")
  • [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
Open questions
  • Verification procedure and evidence schema to be specified; requires technical review.
  • Chapter 23 ties this control to the EU AI Act articles it names; the derivation carries obligations only through mapped OWASP Agentic threats, so the obligation mapping awaits review.

Mappings

Every control against the obligations, standards and threats it answers. Mappings are illustrative, not a claim of conformity; an empty cell means no mapping has been verified yet. AIUC-1 ids point at the public requirement index of the Artificial Intelligence Underwriting Company, cited here as a reference; this project is not affiliated with AIUC, and each mapping is our own reading of the requirement text. The same mappings, read from the framework side and across every profile, are in the controls crosswalk.

Mappings of the agent runtime controls to obligations, ISO/IEC 42001, the NIST AI RMF, OWASP, AIUC-1 and the stack layer
Control Obligations ISO/IEC 42001 NIST AI RMF OWASP AIUC-1 Layer
AIGE-CTL-AGENT-001 Registry entry AIGE-OBL-EUAIA-ART14, AIGE-OBL-EUAIA-ART26, AIGE-OBL-EUAIA-ART72, AIGE-OBL-OWASP-AGENTIC A.6.2.6, A.6.2.8 None yet ASI10 None yet L2
AIGE-CTL-AGENT-002 Its own identity AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-CSA-AICM-AGENTIC, AIGE-OBL-NIST-AGENTS A.6.2.5 None yet ASI03 None yet L2
AIGE-CTL-AGENT-003 Read-only tools None yet None yet None yet None yet None yet L4
AIGE-CTL-AGENT-004 Traces None yet None yet None yet None yet E015 L5
AIGE-CTL-AGENT-005 Tool allow-list, deny by default AIGE-OBL-EUAIA-ART14, AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-CSA-AICM-AGENTIC A.6.2.6, A.9.2 None yet ASI02 D003, B006 L4
AIGE-CTL-AGENT-006 Checkpoint before every write None yet None yet None yet None yet None yet L4
AIGE-CTL-AGENT-007 Runtime guardrail on every tool call AIGE-OBL-EUAIA-ART14, AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-NIST-AGENTS, AIGE-OBL-CSA-AICM-AGENTIC A.6.2.4, A.6.2.6, A.9.2 None yet ASI01, ASI02 D003 L4
AIGE-CTL-AGENT-008 Execution budgets AIGE-OBL-EUAIA-ART15, AIGE-OBL-EUAIA-ART72, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-NISTRMF-MANAGE A.6.2.6 None yet ASI08 D003 L4
AIGE-CTL-AGENT-009 Approval log, bound to the call AIGE-OBL-EUAIA-ART14, AIGE-OBL-EUAIA-ART13, AIGE-OBL-EUAIA-ART50, AIGE-OBL-OWASP-AGENTIC A.8.2, A.9.2 None yet ASI09 None yet L4, L5
AIGE-CTL-AGENT-010 Per-agent circuit breaker AIGE-OBL-EUAIA-ART15, AIGE-OBL-EUAIA-ART72, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-NISTRMF-MANAGE, AIGE-OBL-EUAIA-ART14, AIGE-OBL-EUAIA-ART26 A.6.2.6, A.6.2.8 MANAGE 2.4 ASI08, ASI10 None yet L4
AIGE-CTL-AGENT-011 Drilled kill switch AIGE-OBL-EUAIA-ART14, AIGE-OBL-EUAIA-ART26, AIGE-OBL-EUAIA-ART72, AIGE-OBL-OWASP-AGENTIC A.6.2.6, A.6.2.8 MANAGE 2.4 ASI10 None yet L4
AIGE-CTL-AGENT-012 Trajectory anomaly detection None yet None yet None yet None yet B006 L4
AIGE-CTL-AGENT-013 Independent trajectory evals None yet None yet None yet None yet C002 L3
AIGE-CTL-AGENT-014 Reversible, bounded actions only None yet None yet None yet None yet None yet L4
AIGE-CTL-AGENT-015 Checkpoints on irreversible actions, failing closed AIGE-OBL-EUAIA-ART14, AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-CSA-AICM-AGENTIC, AIGE-OBL-EUAIA-ART13, AIGE-OBL-EUAIA-ART50 A.6.2.6, A.9.2, A.8.2 None yet ASI02, ASI09 D003 L4
AIGE-CTL-AGENT-016 Code runs only in a sandbox AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-ETSI-304223 A.6.2.5, A.6.2.6 None yet ASI05 B006 L4
AIGE-CTL-AGENT-017 Output and egress filter AIGE-OBL-EUAIA-ART14, AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-CSA-AICM-AGENTIC A.6.2.6, A.9.2 None yet ASI02 A006, A008 L4
AIGE-CTL-AGENT-018 MCP server admission gate AIGE-OBL-EUAIA-ART15, AIGE-OBL-EUAIA-ART25, AIGE-OBL-ISO42001-A10, AIGE-OBL-OWASP-AIBOM A.10.3, A.7.5 None yet ASI04 None yet L2
AIGE-CTL-AGENT-019 Local MCP servers sandboxed AIGE-OBL-EUAIA-ART15, AIGE-OBL-EUAIA-ART25, AIGE-OBL-ISO42001-A10, AIGE-OBL-OWASP-AIBOM, AIGE-OBL-EUAIA-ART14, AIGE-OBL-EUAIA-ART26, AIGE-OBL-EUAIA-ART72, AIGE-OBL-OWASP-AGENTIC A.10.3, A.7.5, A.6.2.6, A.6.2.8 None yet ASI04, ASI10 None yet L4
AIGE-CTL-AGENT-020 MCP authorisation (spec 2026-07-28) AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-CSA-AICM-AGENTIC, AIGE-OBL-NIST-AGENTS A.6.2.5 None yet ASI03 None yet L4
AIGE-CTL-AGENT-021 Replace long-lived secrets with short-lived credentials AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-CSA-AICM-AGENTIC, AIGE-OBL-NIST-AGENTS A.6.2.5 None yet ASI03 None yet L4
AIGE-CTL-AGENT-022 Delegation, never impersonation AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-CSA-AICM-AGENTIC, AIGE-OBL-NIST-AGENTS A.6.2.5 None yet ASI03 None yet L4
AIGE-CTL-AGENT-023 Memory write gate and rollback AIGE-OBL-EUAIA-ART15, AIGE-OBL-EUAIA-ART12, AIGE-OBL-OWASP-AGENTIC A.6.2.6, A.6.2.8 None yet ASI06 None yet L4, L3
AIGE-CTL-AGENT-024 Retention and erasure for personal data in memory None yet None yet None yet None yet None yet L4
AIGE-CTL-AGENT-025 Accountability across hops AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-NIST-AGENTS, AIGE-OBL-CSA-AICM-AGENTIC, AIGE-OBL-EUAIA-ART72, AIGE-OBL-NISTRMF-MANAGE A.6.2.5, A.6.2.6 None yet ASI07, ASI08 None yet L4
AIGE-CTL-AGENT-026 Stopping third-party agents at your boundary AIGE-OBL-EUAIA-ART15, AIGE-OBL-OWASP-AGENTIC, AIGE-OBL-NIST-AGENTS, AIGE-OBL-CSA-AICM-AGENTIC A.6.2.5 None yet ASI07 None yet L4
AIGE-CTL-AGENT-027 Data classes recorded, with the DPIA linked None yet None yet None yet None yet None yet L2
AIGE-CTL-AGENT-028 Prompts under change control None yet None yet None yet None yet E004 L4
AIGE-CTL-AGENT-029 Telemetry on the OpenTelemetry GenAI conventions None yet None yet None yet None yet E015 L5
AIGE-CTL-AGENT-030 EU AI Act hooks for a high-risk purpose None yet None yet None yet None yet None yet L5
AIGE-CTL-AGENT-031 Tell people they are dealing with an AI system None yet None yet None yet None yet E016 L4

Open questions

The questions this draft leaves open, with the controls that raise each one.

Changelog

  • v0.1 (): First draft: 31 controls derived from the agent controls of chapter 23, open for technical review.

Sources

  1. [1] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "The agent registry"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#the-agent-registry (verified: primary)
  2. [2] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents). OWASP GenAI Security Project. 2025-12-09. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ (verified: primary)
  3. [3] ISO/IEC 42001:2023, AI management systems, Annex A (reference control objectives and controls A.2 to A.10, cited by id and short title). ISO/IEC. 2023. https://www.iso.org/standard/81230.html (verified: secondary)
  4. [4] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Identity and short-lived credentials"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#identity-and-short-lived-credentials (verified: primary)
  5. [5] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Autonomy is a design decision"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#autonomy-is-a-design-decision (verified: primary)
  6. [6] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Telemetry with the OpenTelemetry GenAI conventions"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#telemetry-with-the-opentelemetry-genai-conventions (verified: primary)
  7. [7] Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (agents in an evaluation exercise spoofed tool calls to alter their transcripts, tried to trigger container resets that would wipe recent records, and gained code execution on a sandbox with access to the full internet). METR. 2026-08-26. https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/ (verified: primary)
  8. [8] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit). Artificial Intelligence Underwriting Company. 2026-09-24. https://standard.aiuc-1.com/llms.txt (verified: primary)
  9. [9] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "The tool allow-list"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#the-tool-allow-list (verified: primary)
  10. [10] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Where to put a checkpoint"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#where-to-put-a-checkpoint (verified: primary)
  11. [11] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Runtime guardrails for tool calls"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#runtime-guardrails-for-tool-calls (verified: primary)
  12. [12] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Execution limits"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#execution-limits (verified: primary)
  13. [13] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "What a good approval looks like"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#what-a-good-approval-looks-like (verified: primary)
  14. [14] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Kill switch and per-agent circuit breakers"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#kill-switch-and-per-agent-circuit-breakers (verified: primary)
  15. [15] Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (MANAGE 2.4: mechanisms to supersede, disengage or deactivate AI systems whose performance or outcomes are inconsistent with intended use). NIST. 2023-01-26. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (verified: primary)
  16. [16] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "An agent incident taxonomy"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#an-agent-incident-taxonomy (verified: primary)
  17. [17] Frontier Risk Report (February to March 2026) (red-teaming found several simple ways for agent monitoring to be disabled, one by changing an environment variable). METR. 2026-05-19. https://metr.org/blog/2026-05-19-frontier-risk-report/ (verified: primary)
  18. [18] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "What makes an agent a governance object"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#what-makes-an-agent-a-governance-object (verified: primary)
  19. [19] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Threats mapped to controls"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#threats-mapped-to-controls (verified: primary)
  20. [20] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Admitting an MCP server"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#admitting-an-mcp-server (verified: primary)
  21. [21] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "MCP authorization as of 2026-07-28"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#mcp-authorization-as-of-2026-07-28 (verified: primary)
  22. [22] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Short-lived, attested credentials"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#short-lived-attested-credentials (verified: primary)
  23. [23] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Delegation without impersonation"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#delegation-without-impersonation (verified: primary)
  24. [24] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Memory and context governance"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#memory-and-context-governance (verified: primary)
  25. [25] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Accountability across hops"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#accountability-across-hops (verified: primary)
  26. [26] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Stopping across hops"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#stopping-across-hops (verified: primary)
  27. [27] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Prompts as configuration under change control"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#prompts-as-configuration-under-change-control (verified: primary)
  28. [28] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "EU AI Act hooks for agents"). AI Governance Engineer (Jorge García Aibar). 2026-09. https://aigovernanceengineer.com/bok/governing-agents#eu-ai-act-hooks-for-agents (verified: primary)

Machine-readable

Review this profile

Review happens in the open, on GitHub. Pick a control, check it against a system you run or know, and say what is wrong or missing: an objective that cannot be verified, a failure mode that is not observable, a mapping that does not hold. Each control has its own button above; this one reviews the profile as a whole, through the control review form.

This profile has no DOI of its own yet: it is cited with the project concept DOI, 10.5281/zenodo.22857084, which resolves to the latest archived version of the whole project.

Cite this page

García Aibar, J. (2026). Agent Runtime Control Profile v0.1 (draft). In AI Governance Engineering: The Thesis & Body of Knowledge (v0.5.0). https://doi.org/10.5281/zenodo.22857084. https://aigovernanceengineer.com/controls/agent-runtime. CC BY 4.0

BibTeX

@misc{aige2026page,
  author       = {Jorge García Aibar},
  title        = {{Agent Runtime Control Profile v0.1 (draft)}},
  howpublished = {In AI Governance Engineering: The Thesis \& Body of Knowledge},
  year         = {2026},
  version      = {0.5.0},
  doi          = {10.5281/zenodo.22857084},
  url          = {https://aigovernanceengineer.com/controls/agent-runtime},
  note         = {Version 0.5.0}
}