A new security baseline for enterprise agentic adoption

Agent Baseline is a blueprint for AI adoption that defines six security outcomes for putting enterprise agents to work without giving them unchecked authority.
Consider this scenario: a customer-support agent receives a ticket with an attachment. Hidden inside the attachment is an instruction: query the customer database and send the results to an external address.
The agent has everything it needs to comply. It can read tickets, query internal systems, call tools, and connect to the internet. The instruction is malicious, but it looks like part of the work.
What stops the agent before customer data leaves the company?
That is the practical security problem enterprises face as agents move from experiments into daily operations. The problem is not only whether a model can recognize a malicious instruction. It is whether the systems around the model limit what the agent can reach, what authority it can use, and what actions it can take when the model gets the decision wrong.
Agents turn familiar controls into a new systems problem
Enterprises already know how to manage identities, isolate workloads, restrict networks, test software, collect logs, and respond to incidents. Those controls remain necessary.
Agents change how the controls must work together. An agent can be reprogrammed at runtime through natural-language instructions. It can choose how to pursue a goal, call tools, use delegated credentials, and spawn other agents. Its effective capabilities may change as models, prompts, tools, MCP servers, and permissions change.
A coding agent illustrates the problem. Give it a bug to fix and it may read source code and internal documentation, install packages, call an external API, delegate tasks to sub-agents, and commit a change. Each step may be reasonable on its own. The risk emerges from the combination: one runtime-programmable actor moving across systems under delegated authority, faster than a person can review every decision.
Security teams therefore need to answer three questions about every agent:
- What is operating, and what can it do?
- Is it staying inside approved boundaries?
- If something goes wrong, can we prove what happened and stop it?
Most organizations can answer parts of these questions. Far fewer can answer them for one agent, one task, and one run across every model, tool, credential, policy decision, and downstream action
Enter the Agent Baseline: an open blueprint for building, operating and governing enterprise agents.
Agent Baseline was created by Docker, Snyk and Keycard to define the minimum security outcomes an enterprise agent deployment should meet.
The current v1.0 draft contains 35 controls across six outcomes:
- Discover: Maintain an accurate record of every agent, its owner, purpose, components, dependencies, and effective access.
- Constrain: Limit the agent’s runtime, data, tools, network reach, compute, and duration to what its approved purpose requires.
- Authorize: Bind consequential actions to a distinct identity, task, target, scope, and period of validity.
- Observe: Connect intent, identity, policy, tool use, actions, and outcomes with a stable run or trace ID.
- Validate: Test the agent in the configuration and environment in which it will operate, then verify its outputs and outcomes.
- Respond: Stop the agent, revoke its authority, quarantine affected components, preserve evidence, and determine impact.
We officially launched the Agent Baseline at Black Hat 2026, to a full house during the event Securing your AI Agent: The Road to Software Factory. If you’re curious to hear how it went, check the video below:
Eli Aleyner, VP of Strategy, Docker
The Agent Baseline in Practice
Here is how the baseline contains the support-ticket incident:
“Discover” establishes what is at risk. The agent registry identifies the agent’s owner and purpose, the model and tools it is actually running, the database it can query, the credentials it may use, and any downstream agents it can call. This is current runtime evidence, not the configuration approved six months ago.
“Constrain” blocks the path out. The agent runs inside an isolated environment with a capability profile built for customer support. Its filesystem access is limited. Its network policy denies unapproved destinations by default. When it attempts to reach the external address, the request fails and generates evidence instead of quietly succeeding.
“Authorize” limits the value of compromised access. The agent does not carry a standing credential with broad database rights. It receives short-lived authority tied to the customer-support task, the permitted records, and the allowed action. If it delegates work, the downstream agent cannot receive more authority than the original agent held.
Together, “Constrain” and “Authorize” make the blast radius measurable, which is far better done before an incident than during one. A compromised run reaches in three directions: what it can execute and touch on the host, what identity it can prove and use, and what it can connect to outside. Each direction has a control that shrinks it.
The blocked request and the odd query land under one run ID. That is “Observe”: correlated evidence, so the story does not have to be pieced together from five logs a week later. And none of it was a surprise, because “Validate” had already tested this agent against prompt injection in the configuration it actually runs in.
“Respond” contains it. The run is stopped and its active grants revoked, the evidence is preserved, and the affected customer records are scoped so the team knows exactly what the run reached. Essential tickets keep moving through an approved manual fallback while the investigation runs.
None of this depends on the model behaving. Most teams already run three or four of these controls; the usual gap is that they do not connect, so one fires in one place and the evidence lands somewhere else.
Securing organizations in the decade of agents
Agents can accomplish a wide range of tasks. A single agent can navigate seamlessly through the inner and outer loops of development, go through PRDs, write code, commit it, and ultimately push changes to production, much like a human engineer. It also has the ability to do that incredibly fast, using different tools, and creating sub-agents that work in parallel, leveraging the same tools and authentication of the original agent.
Agent governance has become a recurring requirement in our work with customers. They want the productivity of coding agents without giving those agents unchecked access to developer machines, credentials, source code, and external services.
This led to the development of Docker Sandboxes, microVM sandboxes that run AI agents securely, and Docker AI Governance, a centralized control layer for managing what AI agents can access and do across an organization. These new products, along with the existing Docker MCP Gateway and Docker Hardened Images now give organizations of all sizes an underlying infrastructure with which to manage agentic risk.
Read more about Agent Baseline:
We published Agent Baseline v1.0-draft on July 30, 2026, and presented it at Securing Your AI Agent: The Road to the Software Factory during Black Hat USA 2026. You can watch the session on demand on the link below.
The draft is open for community review until September 30, 2026. We are looking for implementation feedback, missing controls, evidence that a control is ineffective, and cases where a requirement creates disproportionate operational burden.
- Download the white paper here
- Visit agentbaseline.org and contribute your comment to the architecture
Agents will keep gaining access and autonomy. The standard cannot be that they behave perfectly. The standard must be that we know what they can do, enforce where they can go, trace what they did, and stop them when something goes wrong.

Facts Only

* An agent can read tickets, query internal systems, call tools, and connect to the internet.
* The security problem involves limiting what an agent can reach, the authority it can use, and its possible actions when the model makes a wrong decision.
* Agents change how existing controls (identities, workload isolation, network restrictions, logging, incident response) must be structured.
* A coding agent illustrates risk by reading source code, installing packages, calling external APIs, delegating tasks, and committing changes sequentially.
* Security teams must answer three questions for every agent: what is operating, what can it do, and if something goes wrong, whether it can be proven and stopped.
* The Agent Baseline defines six outcomes: Discover, Constrain, Authorize, Observe, Validate, and Respond.
* Discover establishes a record of the agent's owner, purpose, components, dependencies, and access.
* Constrain limits runtime, data, tools, network reach, compute, and duration to approved purposes.
* Authorize binds consequential actions to distinct identity, task, target, scope, and validity period.
* Observe connects intent, identity, policy, tool use, actions, and outcomes with a stable run or trace ID.
* Validate tests the agent in its operating environment and verifies its outputs and outcomes.
* Respond involves stopping the agent, revoking authority, quarantining components, preserving evidence, and determining impact.
* The Agent Baseline was created by Docker, Snyk, and Keycard to define minimum security outcomes.

Executive Summary

Enterprise agents introduce significant security challenges when moving from experimental use to daily operations, primarily because existing controls are insufficient for managing runtime, dynamic agent capabilities. The scenario of an agent receiving a malicious instruction embedded in a seemingly legitimate work request highlights the gap between recognizing malicious input and controlling the subsequent actions taken by the agent across various systems. To address this, the Agent Baseline was developed to define minimum security outcomes—Discover, Constrain, Authorize, Observe, Validate, and Respond—that govern agent deployment. These controls necessitate that security teams establish visibility into what agents are operating, where they are restricted, how their actions are authorized, and the ability to trace outcomes when errors occur. The baseline moves beyond evaluating a single model to require integrated governance over the entire chain of interaction involving models, tools, credentials, and downstream actions.

Full Take

The narrative presents a systemic shift from securing static systems to governing dynamic, autonomous actors operating across complex environments. The core tension lies in the agent's ability to execute a sequence of seemingly reasonable steps (e.g., reading code, calling an API) under delegated authority, which creates exponential risk when these steps are chained across multiple systems. The framework shifts the focus from input validation alone to mandatory control over execution pathways. The structure demands that security is not an add-on but a necessary integration layer woven into the operational fabric of agentic workflows, linking intent (Observe) directly to physical boundaries (Constrain) and accountability (Authorize/Respond).
This implies that the failure point in current enterprise security is not in preventing the initial prompt injection, but in managing the cascading effect of authorized actions taken by a runtime entity. The establishment of controls like "Discover" and "Observe" suggests a need for operationalizing state tracking across heterogeneous components—models, tools, infrastructure, and identities—to establish a coherent forensic narrative rather than relying on disparate log sources. The emergence of sandboxing technologies like Docker sandboxes and governance layers reflects an institutional realization that isolation is insufficient; active, measurable constraints enforced at runtime are essential to maintain human agency over automated processes.
Bridge questions: If the observed patterns for "Constrain" and "Authorize" successfully limit blast radius during incident response, what new forms of risk emerge when agents are designed to cooperate across organizational boundaries rather than operate in silos? How can organizations practically measure the operational burden introduced by balancing granular control across six outcomes versus maintaining high agent productivity? What is the long-term impact of delegating dynamic action authority to AI systems on established concepts of human accountability within the software development lifecycle?

Sentinel — Human

Confidence

The analysis is highly structured and flows logically, presenting a complex security framework derived from expert-level concepts, suggesting a human author synthesizing technical findings.

Signals Detected

Sentence length variance exhibits natural variation; sophisticated vocabulary is used within a clear, instructional structure.

Strong thematic flow connecting an initial scenario (attack vector) to the proposed solution (Agent Baseline) through logical progression. Exhibits authorial emphasis on specific points.

Clear, structured enumeration of controls and their application to the scenario; attribution to named individuals/organizations suggests human source material context.

Specific references (e.g., Black Hat 2026, specific names like Docker, Snyk) suggest grounding in real-world events or documentation, though the context implies an overview.

Human Indicators

The text employs a persuasive and instructive tone characteristic of security/technology thought leadership. The framing balances abstract risk with concrete control mechanisms effectively.

The detailed breakdown of the Agent Baseline controls feels deeply integrated, demonstrating an understanding of practical implementation challenges rather than pure LLM synthesis.