Docker's Agent Baseline bets that blast radius, not model judgment, is the agent security problem

Docker, Snyk and Keycard have published Agent Baseline, an open blueprint for building, operating and governing enterprise agents, and its v1.0 draft contains 35 controls grouped under six security outcomes ^[1][2]. The framing matters more than the count: Docker argues the practical problem is not only whether a model can recognize a malicious instruction, but whether the systems around the model limit what an agent can reach, what authority it can use, and what actions it can take when the model gets a decision wrong ^[3]. The worked example in Docker's post is a customer-support agent that receives a ticket with an attachment containing a hidden instruction to query the customer database and send the results to an external address ^[4]. The agent can read tickets, query internal systems, call tools and connect to the internet, so it has everything it needs to comply, and the malicious instruction looks like part of the work ^[5][6]. In that configuration, detection is doing the entire job on its own. Docker's second example is a coding agent given a bug to fix, which may read source code and internal documentation, install packages, call an external API, delegate to sub-agents and commit a change ^[7]. Each step can be defensible in isolation; the company's argument is that risk comes from the combination, one runtime-programmable actor moving across systems under delegated authority faster than a person can review every decision ^[8]. Docker also notes that an agent's effective capabilities shift as models, prompts, tools, MCP servers and permissions change, which makes a point-in-time review a weak control ^[9]. The blueprint reduces this to three questions per agent: what is operating and what can it do, is it staying inside approved boundaries, and if something goes wrong can the team prove what happened and stop it ^[10]. According to Docker, most organizations can answer parts of these, and far fewer can answer them for one agent, one task and one run across every model, tool, credential, policy decision and downstream action ^[11]. The six outcomes are Discover, Constrain, Authorize, Observe, Validate and Respond ^[12]. Discover means keeping an accurate record of every agent, its owner, purpose, components, dependencies and effective access ^[13]. Constrain means limiting runtime, data, tools, network reach, compute and duration to what the approved purpose requires ^[14]. Authorize means binding consequential actions to a distinct identity, task, target, scope and period of validity ^[15]. Observe means connecting intent, identity, policy, tool use, actions and outcomes with a stable run or trace ID ^[16]. Validate means testing the agent in the configuration and environment where it will run, then verifying outputs and outcomes ^[17]. Respond means stopping the agent, revoking its authority, quarantining components, preserving evidence and determining impact ^[18]. Applied to the support ticket, Docker says Discover establishes what is at risk using current runtime evidence rather than the configuration approved six months ago ^[19]. Constrain is the step that blocks the exit: an isolated runtime with a support-specific capability profile, limited filesystem access, and a network policy that denies unapproved destinations by default, so the outbound request fails and generates evidence instead of quietly succeeding ^[20]. Authorize, in Docker's account, limits the value of any access that is compromised ^[21]. Two caveats operators should hold onto. This is a vendor-authored document from three companies, not a standards body, and it defines minimum security outcomes rather than implementations ^[1][22]. And 35 controls over six outcomes averages fewer than six controls per outcome, which is thin enough that the specifics will live in whatever tooling each buyer already has ^[23]. What to watch: whether v1.0 leaves draft status, whether the Discover control produces a registry that reflects runtime rather than intent, and whether anyone beyond the three authors commits to being audited against it.