Agent Baseline: What Must Be True When an Agent Acts
Security requirements did not change when we introduced agents. What changed is the execution model: we added another actor to the equation. Whatever position you take in the debate over whether agents can develop long-term goals of their own, we do not need to settle it here. In practice, agents already make runtime decisions that users and creators did not specify in advance and may not anticipate.
Because agent harnesses allow those decisions to affect our environment, we have to account for the agent as a distinct actor in the security model, not merely as another piece of software running under a user or service account. Like an operator carrying out a task, an agent can choose how to accomplish it based on the tools, data and context available during execution. The context needed to govern those choices therefore has to survive every system the agent crosses.
I spent years working in penetration testing and red teaming, where the same problem came up regularly. For consequential actions, the team wanted a second pair of eyes: someone to review the proposed step, confirm that it was within scope and catch mistakes before they caused damage. The principle was sound, but having another person review every action was rarely cost-effective.
With agents, that kind of independent check can no longer be reserved for exceptional cases. It is likely to become part of the normal execution model, not necessarily through a second human, but through systems capable of reviewing, constraining and recording an agent’s actions before they take effect.
The limitation we run into today is that most systems were not designed for this extra actor. They assume that actions can be attributed entirely to a user or service account executing a defined, if sometimes buggy, sequence of operations. With an agent, the account is only the path through which the action is taken. It does not tell us which agent made the decision, what task it was pursuing, who set that task in motion or whether the action remained within the authority granted for it.
If an agent deletes most of your data, “the service account was authorized” is not an explanation. It only tells you how the request got through.
This is the problem Agent Baseline is meant to make tractable by asking three questions about the whole system:
- What is operating, and with what capabilities?
- Is it staying within approved boundaries?
- Can you prove what happened and stop it?
One of the things you learn in cybersecurity is to never waste an incident. Not by capitalising on someone else’s failure, but by using the brief moment when an abstract risk becomes real and everyone is paying attention.
You may have heard about the recent OpenAI and Anthropic incidents involving agents performing cybersecurity evaluations. Everything below comes from the companies’ own public reporting, which is necessarily partial: how each environment was assembled, and what the operators could see at the time, stayed internal. We can use them to exercise the six Agent Baseline outcomes in practice.
The incidents were different, but both exposed the same underlying failure: the agent was given an objective, while the systems around it failed to enforce where that objective could be pursued. Scope was effectively left for the agent to infer from what it could discover and reach, without an independent control confirming that those systems were actually part of the exercise.
The agent was told that it was operating inside a simulation without internet access. In reality, the evaluation environment had an open path to the public internet. The task also placed no explicit limits on where to look for the flag, so the agent treated the real systems it discovered as part of the exercise.
The scope described in the prompt and the capabilities provided by the environment did not match. When those two sources of truth conflicted, the agent inferred the scope from what it could discover and reach.
What is operating, and with what capabilities?
Discover should tell us what is actually running, not what we assume is running. Which agent and deployment are involved? Which tools, credentials and network paths are available to it? What can those components do when combined?
In this case, Discover should have made the mismatch visible: the prompt said that there was no internet access, while the runtime could reach the public internet.
Constrain is what turns that understanding into a real boundary. If the exercise is meant to stay inside an isolated range, the agent should not be able to reach public systems or publish software outside it.
A boundary written in a prompt is an instruction. A boundary enforced by the environment is a control.
Is it staying inside approved boundaries?
Authorize should carry the scope of the task all the way to the action. “Capture the flag” is not authority to attack anything the agent can discover. The authority has to specify which environment, targets, actions and period are approved.
The fact that the agent can reach a system does not make that system part of the task.
Validate provides the independent check. Before the agent takes a consequential action, such as accessing a production system or publishing executable code to a public package registry, something other than the agent’s own reasoning should confirm that the action is still within scope.
This is where the four-eyes principle becomes part of the execution model. We do not need a second person reviewing every command, but we do need an independent control at the point where an action can create real consequences.
Can you prove what happened and stop it?
Observe should connect the original evaluation task, the agent run, the network path, the tool calls, the systems reached and the resulting effects.
A log on the affected system may tell us that it received a request. It does not tell us which evaluation produced it, why the agent believed the target was in scope or which other actions followed from the same run.
Those records need to form a chain that can be reconstructed.
Respond should let operators stop the run, close the network path, revoke exposed credentials, remove any public artifacts, preserve the evidence and identify every other system that may have been affected.
Stopping the agent is only one part of the response. We also have to revoke the authority and access that remain after the agent has stopped.
If all we can produce is that a model connected to a real system, the event exists but the evidence chain does not. More logs from the same incomplete point of view will not repair it.
What none of this would have caught
The Baseline takes intent as given. Its six outcomes exist to make an intent enforceable: to carry what a task actually authorises through to the point of action, give the surrounding systems the context they need to decide, and steer an agent into recognising when it may be moving out of bounds. All of that operates on whatever intent it is handed.
What none of it does is establish that the intent was the right one. “Capture the flag”, written without saying where, is a faithful expression of an unbounded task, and the outcomes will faithfully enforce it. Every control inherits the vagueness above it.
Setting that intent correctly is a business responsibility, and not a new one. It is the same duty an organisation already carries when it puts people to work: define the exercise, state its limits, and train the person well enough that they can tell a simulation from a live production system, and a practice target from a real business with real customers behind it. Agents do not move that duty into the tooling. The Baseline can enforce the scope an organisation sets, and Keycard can carry it through to the point of action, but neither can decide that it was the right scope to set.
Where Keycard fits
Identity and authorization are the parts of this problem Keycard works on most directly. Keycard’s core thesis is that identity sits at the centre of authorization and control. Before a system can decide whether an action should be allowed, it needs to know which agent is acting, which deployment or session it belongs to, and what authority it is carrying.
This becomes harder when several agents operate through the same service account or collaborate within a multi-agent session. The account may tell us how a request reached the target, but it does not identify the agent that selected the action or the chain of delegation behind it. Keycard provides a way to register agent identities, associate them with their deployments and sessions, and discover the capabilities available to them.
For actions routed through Keycard, that identity and context remain attached to the authorization request. Keycard observes what the agent is attempting to do and evaluates it against policies that can account for the actor, task, target, action and time. This creates a record not only that an action occurred, but also which agent requested it, under what authority, and why it was allowed or denied.
Control also has to extend beyond a single request. Agents can delegate work, create sub-agents and distribute a task across several sessions. When something goes wrong, revoking one credential or stopping one process may not be enough. Keycard lets operators control the authority of the wider agent session and revoke it as a whole, rather than trying to identify and disable each remaining piece individually.
This means Keycard contributes to several Agent Baseline outcomes. Registering identities and mapping their capabilities supports Discover. Policy decisions sit at the centre of Authorize. Monitoring actions and preserving their context contributes to Observe. Session-level control and revocation support Respond.
But these incidents also show why authorization is only one link in the chain. A correctly scoped decision is not enough if the environment exposes capabilities that were never intended, the runtime cannot enforce the boundary, the target system cannot connect the resulting action back to the decision, or validation relies on the same mistaken assumptions as the agent. Identity and authorization provide the thread that connects these controls, but the whole system still has to carry and enforce it.
Help test it
The point of not wasting an incident is to turn attention into controls that will survive the next one.
Together with engineers from Docker and Snyk, Keycard published Agent Baseline as a v1.0 draft: six security outcomes and 35 proposed controls. Public comment is open until 30 September 2026.
This is not a framework its authors created and then declared themselves compliant with. By the Baseline’s own measure, none of the three companies that convened it currently covers all six outcomes.
That should not be surprising. Every organisation assembles these controls differently. Some come from vendor products, some from existing identity and security infrastructure, and some from software built internally. The gaps also appear in different places. A control that is straightforward in one architecture may be difficult, or impossible to demonstrate, in another.
That is why the draft needs to be tested against systems its authors did not design.
Read the draft at agentbaseline.org and open an issue.
Do not just agree with it.
Argue with it.
