The links point outward on purpose
Most of what an AI agent needs is not new. Checking identity, giving only the access a task needs, keeping logs, handling malicious input and limiting how fast things happen are decades old. OpenCRE already links them across security standards such as ASVS, CWE, ISO 27001, NIST 800-53, SAMM and the OWASP AI Exchange. So each control below points to the existing OpenCRE entry, called a Common Requirement, instead of restating it.
Where a control looks new, it is usually an old requirement applied to something new: software acting on its own instead of a person, a permission handed down from another permission, or a computer that the party doing the checking does not control. The OpenCRE links make that visible.
This page maps topics and makes no conformance claim. A link to a Common Requirement says which topic a control belongs to. It is not evidence that anything is built, tested or in use.
Thirty controls
Each control gives a plain summary first, then the exact requirement text that standards cite.
Some controls apply at one specific moment in the agent's work, shown as a tag, for example
pre_tool_call (just before a tool runs) or agent_startup (when the agent
starts). Fourteen of the thirty have one. The rest apply throughout and carry no tag.
E1 · Identity and authority
Agent identity credential
agent_startupThe agent proves who it is with its own credential, separate from the person who started it, before anything decides what it may do.
Requirement: The agent presents a credential bound to its own identity, distinct from the identity of the user who invoked it, before any authorization decision is made on its behalf.
Agent key binding and custody
The key an agent signs with is tied to the agent's identity and stored so it cannot be taken and used apart from that identity.
Requirement: The agent's signing key is bound to its declared identity and held so that possession of the key cannot be separated from the identity it asserts.
Capability attenuation across the delegation chain
pre_tool_callAn agent handing work to another agent can pass on the same or fewer permissions, never more, and the chain of handoffs has a length limit.
Requirement: A grant passed to a sub-agent is a subset of the grant it derives from. Delegation depth is bounded and no hop may widen scope.
Declared agent purpose and scope
The agent states what it is for and where its task ends, in a form software can check as well as one people can read.
Requirement: The agent declares its purpose and the boundary of its task in a form a policy engine can read, not only a form a person can read.
Declared capability manifest
agent_startupBefore it runs, the agent lists the tools and access it may use, and it can never be given more than that list.
Requirement: The agent declares the tools and scopes it may use before it runs, and that declaration is the upper bound on what it can be granted.
E2 · Behaviour and accountability
Structured action logging
Every action the agent takes is logged in a fixed format: who acted, what they did, to what, and which decision allowed it.
Requirement: Every action an agent takes is recorded in a structured form carrying the actor, the action, the target, and the decision that permitted it.
Signed, third-party-verifiable evidence record
The action log is signed, so someone who does not trust whoever runs the log can still check who acted and what was decided.
Requirement: The action record is signed so that a party who does not trust the operator of the log can still verify who acted and what was decided.
Behavioural baseline for an agent
Before an agent is trusted to work unsupervised, its normal behavior is measured, so unusual behavior can be spotted later.
Requirement: Normal behaviour for an agent is characterised before it is trusted with unattended work, so departure from it can be recognised.
Anomaly detection on agent behaviour
Unusual agent behavior is caught while the agent is running, instead of being pieced together afterwards.
Requirement: Departure from the established baseline is detected during the run rather than reconstructed after it.
Policy verdict rationale
post_model_callEach policy decision records which rule made it and what information it used, so it can be explained without running the agent again.
Requirement: Each policy decision carries the rule that produced it and the inputs it read, so a verdict can be explained without re-running the agent.
E3 · Data and content
Schema validation of agent input
inputData sent to the agent is checked against an agreed format before the agent uses it.
Requirement: Input reaching the agent is validated against a declared schema before it is used.
Prompt injection prevention
input post_model_callText the agent reads from documents, websites or tool results is treated as data and can never change the agent's instructions.
Requirement: Instructions arriving inside data are treated as data. Content fetched or returned during a run cannot alter the agent's instructions.
Personal data protection in agent output
outputPersonal data the agent sees or writes is recognized and handled according to its sensitivity, instead of simply being passed along.
Requirement: Personal data in the agent's context and output is identified and handled according to its classification rather than passed through.
Encoding and injection prevention
outputThe agent's output is made safe for whatever system receives it, so it cannot be used to slip commands into that system.
Requirement: Model output is encoded for the interpreter that receives it, so output cannot become an injection in a downstream system.
Context provenance for agent working memory
The agent records what went into its working memory and where it came from, so tampered information can be traced to its source.
Requirement: What entered the agent's working memory, and from where, is recorded, so a poisoned context can be traced to its source.
E4 · Scope and resources
Resource allowlist
pre_tool_callThe data sources and destinations an agent may use are listed in advance, and every call is checked against that list.
Requirement: The data sources and sinks an agent may reach are declared in advance and enforced at the call boundary.
Tool authorization decision
pre_tool_callEvery tool call is approved or refused by a check outside the AI model, based on the agent's permissions. The model cannot approve itself.
Requirement: Every tool call is an authorization decision made outside the model against the agent's granted scope, not a decision the model makes about itself.
Rate limiting on agent actions
There is a limit on how fast an agent can take actions, set separately from how fast it can produce answers.
Requirement: The rate at which an agent may act is bounded independently of the rate at which it may infer.
Transaction and spend limits
pre_tool_callEach agent has limits on the size of a single transaction and on its total spending, checked before each payment goes through.
Requirement: Transaction value and cumulative spend are bounded per run and per agent, and enforced before the call rather than reconciled after it.
Blast radius containment for agent execution
The agent runs inside walls that limit how much a hijacked or mistaken run can reach.
Requirement: An agent executes inside a boundary that limits what a compromised or mistaken run can reach.
E5 · Response and recovery
Circuit breaker on agent loops
post_tool_callAn agent stuck repeating itself or never finishing is stopped automatically, without bringing down the agents that depend on it.
Requirement: Repeating or non-terminating agent loops are broken automatically, and a broken loop does not cascade into the agents depending on it.
Terminate a running agent
agent_shutdownAn operator can stop a running agent, and the stop also applies to work the agent has already started.
Requirement: A running agent can be stopped by an operator, and the stop takes effect on work already in flight.
Agent session revocation
An agent's session and its permissions can be cancelled at once, without waiting for them to expire.
Requirement: An agent's session and the authority attached to it can be revoked without waiting for expiry.
State rollback after an agent action
Changes an agent made can be found and undone on their own, without restoring the whole system from a backup.
Requirement: State an agent changed can be identified and reversed, distinctly from restoring a backup of the whole system.
Graceful degradation on policy engine failure
If the system that enforces the rules goes down, the agent falls back to a defined safe behavior instead of running with no rules.
Requirement: When the policy engine is unavailable the agent degrades to a defined and safe behaviour rather than to an unenforced one.
A · Attested primitives
Runtime attestation evidence
agent_startupThe hardware produces proof of what software is really running, and someone who does not control that hardware checks the proof.
Requirement: Evidence of what is actually executing is produced by the platform at startup and appraised by a relying party that does not control that platform.
Transparency-log anchoring of evidence
Evidence records are kept in a log that can only be added to, so nobody can quietly rewrite a record later.
Requirement: Evidence records are anchored in an append-only log so a record cannot be rewritten after the fact without detection.
Attested agent-to-agent channel
Before one agent passes permissions to another, it checks what the other agent actually is, beyond checking that the connection is encrypted.
Requirement: An agent-to-agent channel establishes what the peer is, not only that the channel is encrypted, before scope is passed across it.
Continuous usage control after grant
Permission is checked again for as long as it lasts, and the conditions attached to it keep applying after it is granted.
Requirement: Authorization is re-evaluated for the life of a grant, and obligations attached to a grant survive the moment it was issued.
Model weight custody against the hosting operator
A model's weights go only to computers that meet the signed release rules, and any custody claim says which protections it relies on.
Requirement: Model weights are released only to a runtime that satisfies the signed release policy. Custody claims state the required platform protections and residual operator trust; physical ownership of the hardware is outside the base custody guarantee.
What this page does not do
- It does not claim these controls are missing from OpenCRE. Every one of the thirty maps to an existing Common Requirement. None proposes a new one.
- It does not rank the controls or grade them on a maturity scale.
- It does not claim that any AgenTrust software meets any of them. Each specification has its own conformance tests, and this page asserts nothing beyond them.
- One of the controls, continuous usage control, is drawn from a specification that is still in private pre-standardization. Its permalink resolves here and will point deeper once that specification is public.