The six-layer framework for governing AI agents
Written by Alex Vakhitov, founder of Comonad Limited. Last reviewed: 28 September 2026.
On this page
Identity and access management (IAM) was designed for two kinds of actor: people, who sign in and act, and services, which run fixed code under fixed permissions. An AI agent fits neither. It decides at run time which tools to call, so one request can become a chain of reads, writes and messages across several systems. It usually acts on behalf of a person, which raises the question of whose authority each step uses. Its intent is shaped by whatever it reads, including content written outside the organisation. A permission granted at sign-in may be used hours later, in a context nobody checked. And when several agents share one human account or one long-lived key, the logs can no longer say which agent did what, or for whom.
These are identity and authority problems before they are model problems. The framework below treats every agent as an accountable identity with bounded, delegated authority, checked at the moment of action and recorded as evidence. It is vendor-neutral, built on open standards and organised in six layers, each with testable controls. For the operating controls that sit alongside it, such as approval design, evaluation and stop runbooks, see our guide to governing AI agents in production.
1. Identity and authentication
Every agent has its own non-human identity, registered with an owner, a purpose, a risk tier and a lifecycle, and proves it with short-lived credentials that rotate automatically.
An agent identity is a workload identity: issued to software, bound to a deployment, and distinct from every person and every other agent. The agent registry is its system of record. Credentials are issued at run time and expire in minutes or hours, using for example OAuth 2.0 client credentials with private-key authentication, workload identity federation, mutual Transport Layer Security (mTLS) or short-lived signed tokens. Shared human accounts and long-lived application programming interface (API) keys fail on both counts: they cannot be attributed to one agent, and revoking them breaks everything else that uses them.
What good looks like
- Every production agent has a registry entry with a unique identifier, owner, purpose, risk tier, version and lifecycle state.
- No agent authenticates with a human account, shared service account or static API key, and a scan of configuration and secrets stores confirms it.
- Agent credentials have a defined maximum lifetime and renew automatically.
- Credentials from unregistered, suspended or retired agents are refused, and the refusal is logged.
2. Authorisation and delegated authority
An agent may do only what its current task needs. When it acts for a person, its authority is the intersection of that person's rights and its own scope, checked against policy at every tool call.
Grant permissions per task and per tool, with read and write separate. For delegation, the agent exchanges the user's token for a narrower one through an on-behalf-of flow or OAuth 2.0 Token Exchange, defined in Request for Comments (RFC) 8693. The authorisation server can then issue a token naming both the user and the agent (the subject and the actor), carrying only scopes both hold. Write policy as code (for example, OPA or Cedar) and evaluate it at every tool call as well as at sign-in, because a permission can lapse between sign-in and use. Grant elevated rights just in time (JIT) for a single task. Irreversible or high-risk actions wait for a named person's approval.
What good looks like
- Permissions are declared per tool and per operation, and anything undeclared is denied by default.
- Tests show that an agent acting for a user is refused anything outside the user's rights or outside its own scope.
- Every tool call produces a recorded policy decision that cites the policy version.
- Elevated permissions expire automatically, and irreversible actions need a recorded approval from someone other than the requester.
3. Control plane and lifecycle
All agents reach models, tools and data through one governed control plane, so one registry, one policy and one off switch apply across teams and vendors.
At scale, the risk is fragmentation: each team connecting agents to tools its own way, with its own keys and logs. A central gateway sits between agents and everything they call: model endpoints, internal APIs and Model Context Protocol (MCP) servers. MCP is the open protocol agents use to connect to tools and data, and each MCP server is a privileged integration that needs registration and review. Permission tiers by risk set what an agent or tool needs before go-live. Onboarding, access reviews and offboarding follow the same discipline as for any identity, and separation of duties applies: whoever builds an agent does not approve its production permissions.
What good looks like
- Agents can reach models, tools and MCP servers only through the gateway.
- Every tool and MCP server is registered with an owner and a risk tier before any agent can call it.
- Access reviews run on a schedule set by risk tier, and unused permissions are removed.
- Suspending an agent in the registry revokes its credentials and gateway access in one step, tested in every release.
4. Accountability
Every agent, and every class of decision it takes, has a named person who answers for it, with written responsibilities and a defined escalation path.
A named owner is an individual; a team alias does not count. A responsible, accountable, consulted and informed (RACI) matrix for each agent records who sets its permissions, approves changes, reviews its behaviour and may switch it off. Group the agent's decisions into classes, such as refunds below a threshold or changes to customer records, and give each class an accountable person. Escalation paths say who is contacted when the agent meets a denial, an anomaly or an approval that times out, and what happens to the work meanwhile.
What good looks like
- Every registry entry names an owner and a deputy, and an agent without a current owner is suspended.
- Each agent has a RACI matrix agreed with security and risk, and each decision class has an accountable person on record.
- Escalation routes for denials, anomalies and approval timeouts exist and have been exercised.
5. Auditability and evidence
Every agent action can be traced end to end: who initiated it, which agent acted, on whose behalf, under which policy, and with what inputs and outputs, in records that cannot be altered without detection.
Because the earlier layers give every actor an identity and every decision a policy version, one trace identifier can link the user's request, the token exchange, each policy decision, each tool call and any approval. Logs are tamper-evident (held in append-only, hash-chained or write-once storage), with retention agreed with legal and risk teams. For systems in scope of the EU AI Act's high-risk requirements, these records support the automatic recording of events under Article 12 and human oversight under Article 14, including the ability to intervene in or stop the system. The framework also maps to ISO/IEC 42001 and the NIST AI Risk Management Framework (AI RMF). Legal sign-off stays with your counsel.
What good looks like
- Any action can be reconstructed from its trace identifier, including the delegating user, agent version, policy version and approver.
- Log integrity is verified automatically, and a missing or altered record raises an alert.
- Each control names the record it produces and the obligations it supports.
6. Runtime security
Assume every agent will meet hostile input, and design its environment to limit what a manipulated agent can reach, see or send.
Prompt injection, where instructions hidden in content the agent reads redirect its behaviour, cannot be reliably prevented by the model alone, and it leads to tool abuse: legitimate tools used for illegitimate ends. The defence is containment. Tools run in sandboxes with only the access the task needs. Egress is limited to approved destinations. Secrets never enter prompts or context; the tool layer adds credentials at call time, outside the model's view. Data boundaries set what each agent may read and where its outputs may go. Red teaming tests the whole agent, tools and permissions included, and monitoring flags anomalies such as unusual tool sequences or spikes in denials.
What good looks like
- Automated scanning confirms that no secret, key or token appears in prompts, context or model logs.
- Agent runtimes and tool sandboxes deny egress by default, with an allowlist for each agent.
- External content is marked untrusted and cannot trigger a high-risk tool without approval.
- Red-team findings are tracked to closure, and anomaly alerts reach the owner and security operations.
A rollout path in three stages
Complete each stage before agents at a higher risk tier go live.
| Stage | What is in place |
|---|---|
| Start | Every agent registered with an owner and risk tier. Workload identities in place of shared accounts and static keys. Least-privilege tool permissions. Approval for irreversible actions. Trace identifiers. A tested off switch. |
| Scale | A central gateway for models, tools and MCP servers. Token exchange for delegation. Policy as code at every tool call. Risk tiers, JIT elevation and access reviews. Sandboxing and egress controls. |
| Assure | Tamper-evident logs with set retention. Evidence mapped to the EU AI Act where it applies, ISO/IEC 42001 and the NIST AI RMF. Regular red teaming and anomaly detection. Periodic review against the control model. |
How Comonad helps
Comonad Limited, a London applied-AI consultancy, puts this framework into practice in the systems you already run.
- Assess. We review your agents, credentials, permissions and logs against the six layers and list the gaps.
- Design. We write the control model: registry, identity and delegation patterns, policy, risk tiers and the evidence each control produces.
- Implement. We build the controls into your own stack and release process as an AI engineering engagement.
- Assure. We review the running system against the control model at agreed intervals, as part of our AI governance work.
Tell us which agents you run or plan to run, and which frameworks your risk team works to.
Book an introductory callFrequently asked questions
How should AI agents authenticate to enterprise systems?
AI agents should authenticate with their own workload identity and short-lived credentials issued and rotated automatically. Common patterns are OAuth 2.0 client credentials with private-key authentication, workload identity federation, mTLS and short-lived signed tokens. Each agent has a distinct identity in an agent registry, so every request can be attributed to one agent and its credentials can be revoked without affecting anything else.
Can an AI agent use a user's account or API key?
No. An agent should never sign in as a person or reuse their API key, because its actions then look identical to theirs and cannot be separately limited, attributed or revoked. To act for a user, the agent should obtain a delegated token through an on-behalf-of flow or OAuth 2.0 Token Exchange (RFC 8693). That token identifies both the user and the agent, and carries only permissions both hold.
How do you stop an AI agent doing more than the user could?
Give the agent the intersection of the user's rights and its own scope, and check it at every tool call. The delegated token carries only permissions both hold, and a policy engine evaluates each action against the user, agent, task and context before it runs. Test the boundary directly: the agent should be refused anything the user could not do, and anything outside its own scope.
What does the EU AI Act require for AI agent logs and human oversight?
The EU AI Act has no agent-specific rules; its logging and oversight duties apply to high-risk AI systems, which an agent may or may not be, depending on its use. For those systems, Article 12 requires automatic recording of events, Article 14 requires design for effective human oversight, including a way to interrupt the system, and Article 26 requires deployers to keep the logs under their control for at least six months. Legal sign-off stays with your counsel.
How do you switch off or revoke an AI agent?
Suspend the agent's identity in the registry, which should revoke its credentials and cut its gateway access in one step. Because each agent has its own identity and short-lived credentials, this stops that agent alone, and any token it still holds soon expires. Decide in advance what happens to work in flight and who may make the call, and test the switch in every release.
How does this framework relate to ISO/IEC 42001?
The framework maps to ISO/IEC 42001 at the level of its management-system themes, such as leadership and roles, risk treatment, operational control and documented information. ISO/IEC 42001 sets requirements for an AI management system, and this framework supplies agent-specific controls and records that fit inside one. Mapping is not certification, which is carried out by accredited certification bodies.