Snyk, alongside Docker and Keycard, published the Agent Baseline: six security outcomes and 35 controls for securing AI agents. This follow-up addresses the practical gap identified at a Black Hat panel — the paper is a coverage test, not a sequencing plan. It proposes prioritizing controls differently depending on use case: developer coding agents should start with Constrain (sandboxing, capability profiles) and calibrate with Discover; shared internal agents should start with Authorize to prevent confused-deputy problems; production agents should prioritize Respond (kill switches, quarantine, non-agent fallbacks) and Validate (checking outcomes, not just permissions). The piece also admits two gaps in the current Baseline draft: no maturity model and no use-case lens in v1.0. The Baseline remains open for public comment until September 30.
Table of contents
The fog is real, and we're deep in itThe missing axis is the use caseThe balance is a design choice, not necessarily a compromiseWhat's not in the paper yetRead it, then contribute to itSecure AI adoption at scaleQuestions this post answers
Which Agent Baseline security controls should I implement first for a developer coding agent?
Start with Constrain, not Discover. Use isolated execution and use-case-scoped capability profiles (CON-03, CON-04) to limit what the agent can access, then add a component registry (DIS-04) for MCP servers, skills, plugins, models, and tools, then apply testing on the way out (VAL-03) so agent-generated code passes the same release gates as any other code. Track evolving AI agent security frameworks like this one on daily.dev as coding agent adoption grows.
What security control matters most for a shared internal AI agent used by multiple employees, like an HR assistant or ops-copilot?
Authorize matters most, because the core risk is a confused-deputy problem, not blast radius. A distinct, verifiable identity per party to an action (AUT-01), task-scoped authority instead of inherited account access (AUT-02), and attenuation down the delegation chain (AUT-03) prevent one user's request from exercising another user's authority through a shared service account. Compare identity and authorization approaches for shared AI agents as governance patterns mature on daily.dev.
What should a kill switch for a production AI agent actually do when triggered?
Per control RES-01 in the Agent Baseline, stopping a production agent means blocking new work, halting runs already in flight, and revoking every credential, permit, delegated grant, and session created by those runs by following the delegation chain rather than just the visible process. Deleting the container while leaving an issued token active does not actually stop the agent. Follow incident-response patterns for AI agents on daily.dev before you need them in production.