The controls one agent needs.

Describe one agent: how much it decides on its own, which tools and MCP servers it calls with what permissions, what data and memory it touches, and how it proves who it is. You get the minimum control set chapter 23 asks for, the gaps to close, an agent register entry and a checklist.

Indicative, not legal advice and not a conformity claim. Nothing you enter leaves your browser.

JavaScript is off or has not loaded, so the live result and the exports are not available. The questions, the criteria and the guide below still work as a worksheet you can read and fill in by hand.

Built from 23. Governing AI agents of the Body of Knowledge. Runs entirely in this page: no account and no upload.

The agent

The register entry's required fields are the id, the owner and the expiry.

No agent outlives its review: the entry deactivates on this date.

Autonomy: what the person does

Autonomy is a design decision, set by the role the person plays, not a property of the model. Least agency first: the cheapest agent control is the autonomy you did not grant.

Tools and MCP servers

One row per tool. The operation class drives the checkpoints; scopes become the register entry's scope. A tool is a capability: no tool is harmless by name.

Tool 1
Tool 2
Tool 3
Tool 4
Tool 5
Tool 6
Data, memory and actions

Data

Memory

External actions

Identity: how it proves who it is

Channel authentication secures one hop; the agent's own identity is what its actions are logged and revoked under.

Approval points and other agents

Where a person approves

Other agents

Purpose, budgets and the stop

Is its intended purpose an EU AI Act Annex III use case?

How the profile is built

An agent is governed when every action traces back to a registered identity, a scope someone approved, a checkpoint that fired where the stakes required one and a tested way to stop it [1]. The tool starts from the minimum set of the autonomy level, adds the controls the agent's tools, memory, identity and delegation call for, and flags where the description breaks one of the chapter's rules.

Minimum controls by autonomy level

The levels follow the user's role as Feng, McDonald and Zhang define it [3]; the alignment with the IMDA levels and ATF tiers and the control sets are chapter 23's reading (autonomy is a design decision). Each level adds to the one above. The tool carries every control up, except the Operator's read-only tools and the Collaborator's checkpoint before every write, which the Approver row narrows to critical or irreversible steps.

What each level adds
Level What the person does Adds
Operator Takes every action Registry entry; Its own identity; Read-only tools; Traces
Collaborator Approves significant steps Tool allow-list, deny by default; Checkpoint before every write
Consultant Sets goals, gives feedback Runtime guardrail on every tool call; Execution budgets
Approver Approves critical or irreversible steps Approval log, bound to the call; Per-agent circuit breaker; Drilled kill switch
Observer Audits after the fact Trajectory anomaly detection; Independent trajectory evals; Reversible, bounded actions only

Controls the agent's design adds

Control, when the tool adds it, and where the chapter sets it out
Control Added when Chapter 23 and pattern
Checkpoints on irreversible actions, failing closed A tool of the pay, delete, send or execute class, or an external action; always at the Approver and Observer levels Where to put a checkpoint · Human-in-the-loop Gate
Code runs only in a sandbox A tool of the execute class, or generated code the agent runs Runtime guardrails for tool calls · Runtime Guardrail
Output and egress filter A send-class tool, messages or publication, or a tool touching confidential or restricted data The tool allow-list · Runtime Guardrail
MCP server admission gate Any tool served by an MCP server Admitting an MCP server · AIBOM
Local MCP servers sandboxed A local MCP server Admitting an MCP server · Shadow-AI Discovery
MCP authorisation (spec 2026-07-28) A remote MCP server over HTTP MCP authorization as of 2026-07-28 · Agent Identity & Scoped Credentials
Replace long-lived secrets with short-lived credentials A static API key or a long-lived secret Short-lived, attested credentials · Agent Identity & Scoped Credentials
Delegation, never impersonation The agent acts for users, or holds the user's own token Delegation without impersonation · Agent Identity & Scoped Credentials
Memory write gate and rollback Long-term or shared memory, or a retrieval corpus Memory and context governance · Runtime Guardrail
Retention and erasure for personal data in memory Long-term or shared memory that may hold personal data Memory and context governance
Data classes recorded, with the DPIA linked Personal data, or confidential or restricted data in a tool The agent registry · Agent Registry
Accountability across hops The agent calls or delegates to other agents, or shares memory with them Accountability across hops · Agent Identity & Scoped Credentials
Stopping third-party agents at your boundary It calls another organisation's agents Stopping across hops · Kill Switch / Circuit Breaker
Prompts under change control Every agent Prompts as configuration under change control · Eval Gate in CI
Telemetry on the OpenTelemetry GenAI conventions Every agent Telemetry with the OpenTelemetry GenAI conventions
EU AI Act hooks for a high-risk purpose Its purpose is, or may be, an Annex III use case EU AI Act hooks for agents
Tell people they are dealing with an AI system It sends messages, emails or calls to people EU AI Act hooks for agents

The register entry

The JSON download validates against the agent-register-entry.v1 schema [7]. Its autonomy_level and human_oversight.mode values are the tool's nearest reading of the five levels (Operator: suggest only; Collaborator and Approver: act with approval; Consultant: act and report; Observer: act autonomously); the chapter's level travels in extensions with the control list and the gaps. Record the level as a registry field and treat raising it as a change that needs the same review as a new deployment.

By hand, without JavaScript

  1. Pick the level from what the person does, and take its row and every row above it.
  2. For each tool, note its operation class; pay, delete, send and execute need a checkpoint that fails closed.
  3. Walk the second table: add each control whose condition your agent meets.
  4. Fill the register fields of the agent registry and drill the incident classes of the agent incident taxonomy that its tools make possible.

What this is not

Not legal advice and not a conformity claim. The controls restate chapter 23 and add none of their own; the threat ids come from the OWASP agentic list [4] and the MCP rules from the 2026-07-28 specification [5], as the chapter reads them. The EU AI Act hooks [6] apply by intended purpose, not by architecture: an agent is classified like any other AI system. Mappings are illustrative, not a claim of conformity.

Each of the 31 controls this tool can select is also published in the agent runtime control profile, one draft reference control per rule, with the evidence it must leave, its mappings and a JSON record. The profile is open for technical review; its verification procedures are still to be specified.

Terms used here

Sources

  1. [1] 23. Governing AI agents: "Autonomy is a design decision" (the minimum controls per level), "The agent registry", "Identity and short-lived credentials", "Tool and MCP server permissions", "Human checkpoints and approval design", "Runtime guardrails for tool calls", "Kill switch and per-agent circuit breakers", "Memory and context governance", "Multi-agent systems and delegation chains", "An agent incident taxonomy" and "EU AI Act hooks for agents", the text this tool derives its controls from. AI Governance Engineering Body of Knowledge. 2026-09-24. https://aigovernanceengineer.com/bok/governing-agents (verified: primary)
  2. [2] Patterns: Agent Registry, Agent Identity & Scoped Credentials, Runtime Guardrail, Human-in-the-loop Gate, Kill Switch / Circuit Breaker, AIBOM, Shadow-AI Discovery and Eval Gate in CI. AI Governance Engineering Body of Knowledge. 2026-09-24. https://aigovernanceengineer.com/patterns (verified: primary)
  3. [3] "Levels of Autonomy for AI Agents" (K. J. Kevin Feng, David W. McDonald, Amy X. Zhang; five levels by user role: operator, collaborator, consultant, approver, observer). arXiv 2506.12469. 2025-06-14. https://arxiv.org/abs/2506.12469 (verified: primary)
  4. [4] OWASP Top 10 for Agentic Applications 2026 (ASI01 to ASI10; least agency). OWASP GenAI Security Project. 2025-12-09. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ (verified: primary)
  5. [5] Model Context Protocol specification, version 2026-07-28, Authorization (RFC 9728 protected-resource metadata; RFC 8707 resource parameter; audience validation; no token passthrough; RFC 9207 issuer validation; step-up scopes). Model Context Protocol. 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization (verified: primary)
  6. [6] Regulation (EU) 2024/1689 (AI Act), consolidated text: Art. 12 record-keeping; Art. 14(3)-(4) human oversight; Art. 26(2) and (6) deployer obligations; Art. 50(1) transparency for systems interacting with natural persons. Publications Office of the EU (EUR-Lex). 2026-07-27. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng#art_14 (verified: primary)
  7. [7] Agent register entry, JSON Schema v1 (identity, owner, scope, expiry, tools, data access, delegation, autonomy level, human oversight, spend limit, kill switch). AI Governance Engineer templates and schemas library. 2026-09-24. https://aigovernanceengineer.com/schemas/agent-register-entry.v1.json (verified: primary)