The Agent Baseline: 35 controls, but where should you start?

Two weeks ago, we published the Agent Baseline alongside Docker and Keycard. In it, we describe six security outcomes, 35 controls, and an open reference architecture for running AI agents at the enterprise level. Last week, we stress-tested it: we took it to a panel at Black Hat and spent about one hour being asked hard questions about it.

Play Video: Snyk x Docker x Keycard | Agent Baseline Panel @ Black Hat 2026

The most useful question came from someone who had actually already read it. She said, roughly: This is right, but I still don't know what to do come Monday.

And that's fair; it's also worth answering properly, because it points to something we chose not to do in the paper. It’s also the kind of gap we are counting on readers to find while the Baseline is still open for comment.

The fog is real, and we're deep in it

If you go looking for help securing AI agents, you will very quickly walk into a wall of claims, because every single vendor in the market (Snyk included) will tell you they solve agent security. Each and every one is describing something real, but what's almost never clear is which part of the problem they're describing, or how their part connects to the other parts you still need.

It's not a matter of dishonesty, though. This is just a symptom of a market that formed faster than its vocabulary. "Agent governance" can currently mean at least five different things depending on who's selling it, and a buyer has no reliable way to tell whether two products overlap, complement each other, or leave a gap between them that nobody has mentioned (or even identified, which is more worrying).

This cuts both ways. Vendors want to clearly say where they add value and how their piece plugs into the rest of a customer’s architecture, but without a shared vocabulary, that comes out as the same undifferentiated claim everyone else is making.

And practitioners need more than a vendor decoder ring: mapping against the six outcomes shows you where you have to look externally versus where you already have internal strength. That is the buy-versus-build conversation, and it is a lot easier to have when the gaps are named.

Take two products, both of which are sold as agent governance, and both of their descriptions are accurate.

The first sits at the edge of the network. It watches every call an agent makes out to the world, can inspect what's in that call, and can block it on policy. It will tell you that a request carrying customer records went somewhere it shouldn't have. What it can't tell you is which skill file put that instruction in the agent's proverbial head in the first place, because none of that ever crosses its path.

The second is an identity layer. It brokers short-lived, scoped credentials at the moment of use, so every action carries a verifiable answer to who set this in motion, and with what authority. It will tell you, precisely, that the agent was allowed to do what it did. What it can't tell you is whether doing it was a good idea.

Now map both against the six outcomes: the first covers parts of Constrain and Observe, the second covers Authorize. Neither is exaggerating, nor overlaps the other, and between them they leave Validate untouched. Nobody has tested whether the agent behaves safely under attack, and nobody has checked what it produced. A buyer who owns both, quite reasonably believing they have agent governance handled, has never once had that conversation, because it didn't come up in either sales cycle.

The Baseline was written exactly to make that comparison possible, as it defines the problem by the security outcomes an organization has to achieve, not by product category: Discover, Constrain, Authorize, Observe, Validate, and Respond. Map any platform, product, or internal build against those six, and we quickly understand exactly where they excel, but also where they might warrant complementary solutions.

What we underweighted was sequencing, because six outcomes and 35 controls is a coverage test, but a coverage test a plan it is not. (Sorry for Yodaling a bit, but this bit of wordplay shows how the sequence is important, too: we covered the meaning, it's intelligible, but the wrong sequence makes it take an extra second to grasp.)

If you go read the paper now as a to-do list, you will not start, because starting looks like a two-year program. So this is the part we owed you: the order.

Most organizations aren’t running a software factory yet

One thing we believed to be true and the Black Hat panel confirmed: very few companies are operating software factories today, and many aren’t building toward one at any real scale. That’s worth saying plainly, because a reference architecture can read as an indictment if you’re not there yet. It isn’t. If you’re on the doorstep (and most people are), this is the scaffolding you build against, and it gives security a role in preparing for that automation and productivity rather than reacting to it after the fact.

The missing axis is the use case

The paper walks up the autonomy curve, from a coding agent on a laptop, to an unattended service patching dependencies at 3 AM. Though that's the right way to explain why the controls exist, it's not the right way to decide which ones you need first, because most organizations aren't climbing a single curve; they are running several different things all at once, and calling all of them "agents".

There are three patterns that cover most of what we see:

1. Developer coding agents. Someone in the org downloads a coding agent and runs it against a real repository.
2. Shared internal agents. There's one agent, and many employees using it, with examples such as the HR assistant, the finance approver, or the ops-copilot.
3. Production agents. These are agents acting on customers, transactions, and systems of record, often with very little "human in the loop".

So, you have 35 controls, but a radically different order by which they're "invoked". The problem is when you start treating them as one program, because the control that matters the most for the first one is close to irrelevant for the third, and vice versa. Get the sequence wrong, and you'll spend months building an agent registry while your actual exposure sits somewhere else entirely.

Developer coding agents: start with Constrain, calibrate with Discover

Now, the instinct here would be to start with discovery: you believe you need to find every single agent, and then decide what to do. In this use case, that's the wrong first move, and the paper explains why in one sentence: a registry and an approval workflow achieve nothing if the agent runs on a host that enforces neither.

Here's what actually happens: a developer installs a coding agent, and it starts asking for permission every time it needs to read a folder or run a command. The constant prompts start to get annoying, so the developer allows common commands, widens filesystem access, or even turns the sandbox off. That's when the agent becomes an ordinary process running as that developer, reaching whatever their shell can reach.

Access grows one connection at a time: GitHub opens an OAuth flow, a cloud tool finds an existing login, an MCP server asks for a token, SSH uses the key already loaded on the machine, and so on. You get the picture.

Every step by itself seems reasonable, but the end result is an agent with broad authority spread across systems that don't share a view of each other, and logs that all say it was the developer who did it.

So, start at the boundary. Isolated execution and use-case-scoped capability profiles (CON-03, CON-04) give the agent only what its class of work needs, defined centrally, versioned, and outside the agent's reach to edit. Then the component registry (DIS-04): MCP servers, skills, plugins, models, tools, with source and version. Then, testing on the way out (VAL-03), because agent-generated code leaves the sandbox through the same release gates as everything else.

The part that surprises people the most is that this will make the developer's day better, not worse. When credentials arrive from a broker at the moment of use, scoped to the task, the agent stops asking for approval on every "harmless" command, because the "harmless" commands can no longer do harm. You get fewer prompts and a tighter boundary from the same control, and that's rare enough to be worth saying out loud.

Which brings discovery back in, not as the first move, but as the thing that makes the first as good as it can be.

A capability profile is only as good as the picture it was drawn from. Write one by assuming, and you get one of two failures: too broad, and the agent starts planning around access to the task never needed, or too narrow, and the boundary gets clicked away one "Always allow" at a time. It's the same root cause both times, which stems from a profile that was written without looking.

So, you’d better look. Effective-access mapping (DIS-06) tells you which identities and credentials an agent can actually reach, and what those permit. The component registry tells you which MCP servers, skills, and models are genuinely in play, rather than the ones you assume are.

And it doesn't stop on day one: reconciliation (DIS-07) is what tells you the profile has drifted: a new MCP server here, and a job that changed shape there. The paper is explicit on this, that discovery isn't a static registry, but a continuously reconciled operational view.

Constrain is where you start enforcing, and Discover is where you learn what to enforce. Sequence them, but don't separate them, as Discover is an extremely important input into determining how constraints should be defined, which should be tackled towards the beginning.

Shared internal agents: start with Authorize

Sandboxing does almost nothing here, because the risk isn't blast radius on a host, it's the "confused deputy". (It's an authority problem. The concept is from Norm Hardy, back in 1988: a program holding legitimate authority gets tricked into exercising it on behalf of the wrong principal. Nothing is compromised, nothing escapes containment, no vulnerability is exploited, but the deputy just can't tell on whose behalf it's acting on.)

The quickest integration gives the agent one service account and lets everyone's requests flow through it. It works immediately... which is the problem. Every request now enters the same pool of access. By the time a request reaches the internal API, the person who made it has disappeared from view, and a prompt from Alice's data can end up exercising authority meant for Bob. Telling the model to keep their work separate is a request, not a boundary.

This is the use case where authority has to be structural: a distinct, verifiable identity for every party to an action, with attribution to the initiating person or an approved autonomous purpose (AUT-01). Authority needs to be scoped to the task rather than inherited from the account (AUT-02): least privilege bounds how much access exists, delegation bounds why, for what, and for how long. And attenuation down the chain (AUT-03), so a downstream agent never receives more authority than its caller held.

Then, correlation (OBS-02), because in a multi-user agent, the audit question isn't "Did something happen?" but "On whose behalf did it happen?". Without a run identifier tying the request to the action, you can't answer that after the fact, and after the fact is when you'll be asked.

Production agents: start with Respond, and with Validate

For agents acting on customers and transactions, the controls that matter are the ones nobody buys until they've needed them. So, start with a question: if you had to stop this agent right now, what would happen to the work?

The issue here is that most teams can't answer that question, and that's where we spot the gap. RES-01 says stopping means blocking new work, halting runs in flight, and revoking the credentials, permits, delegated grants, and sessions those runs created, following the delegation chain, not the visible process. Delete the container, yet leave the token alive, and you've stopped nothing. RES-02 adds the part that is genuinely new: the unit of quarantine is often a component, not a host. A poisoned skill file or a compromised MCP server can be shared across dozens of agents, and because making it available can be as simple as putting a file in a directory, removing one copy removes nothing.

Then RES-04, the control we'd bet is missing almost everywhere: a non-agent fallback for work that can't wait. Once a workflow depends on an agent, the ability to do the work sits with the agent rather than the platform. Stop it, and you strand the work. Which workflows need a documented manual path, and what that path is, are decisions to make before the incident.

And on the Validate side, VAL04: an agent can complete an action successfully and still get the outcome wrong, because permission is not correctness. For irreversible actions in particular, validate the proposed outcome before it's final, not the result afterward.

This is the part of the architecture we spend our time on at Snyk. Not just whether an agent’s code and dependencies are sound, but whether the agent’s behavior stays inside its authority at runtime: what it is allowed to do, on whose behalf, and what happens when it steps outside that. Plenty of the Baseline sits outside our scope, which is rather the point of a vendor-agnostic model.

The balance is a design choice, not necessarily a compromise

The reflex when this gets scary is to block everything: ban the tools, wait for the market to settle, "let's revisit next year".

Now, that doesn't work, and not for the reason usually given. It's not just that the shadow adoption will continue (because it does), but because blocking removes your visibility into the thing you're worried about while the business adopts it anyway, so you end up carrying the same risk, just with less information about it.

But the opposite reflex is even worse: approve everything, sprinkle a bit of monitoring, and call it "governance". Watching an agent isn't the same as bounding it.

What actually works looks less like a decision and more like an architecture. The controls in the Baseline are designed to sit outside the model, because they can't depend on the agent following instructions. That's what makes the productivity conversation tractable, as you're not choosing how much to trust the agent, rather how much authority the work requires, and then enforcing that ceiling somewhere the agent can't argue with it. Below that ceiling, let it run.

Grades matter here, too. A denial that says only "No." invites retries and workarounds, whereas a denial that carries the reason and the governed path forward, registers the component, requests a scoped elevation with a justification, gets independent approval, and steers the run back inside its boundaries without ending it. Between a steer and a stop, there's a reduction in the run's authority in place while a person decides. If you reach for a full stop first, every anomaly becomes an outage of service.

What's not in the paper yet

There are two things missing in the Agent Baseline, and we'd rather be upfront and name them than let you find them.

First, there's no maturity model. The controls tell you what good looks like, but they don't tell you what "stage one good" looks like versus "stage three good". Every organization reading this is at a different point, and a coverage test that treats a Series B and a global bank identically isn't much use to either. Sequencing per use case, of the kind above, is just the start of that work, but it isn't the finishing thing.

And then, the use case lens isn't in v1.0 at all. You found it here because it came out of conversations like the one we had at Black Hat, which is a reasonable argument that the review process is doing its job, and a better argument that we should probably have caught it earlier.

Read it, then contribute to it

We feel very good about this starting point. We also know there are people who have been managing and measuring this work longer than the Baseline has existed, with strong opinions and proof points to back them. That is exactly who we need to hear from, and now is the moment: the Baseline is open for comment until 30 September, and it stays open source either way.

The Baseline is a draft, open for comment until the 30th of September. The controls have permanent identifiers so you can cite them in an audit finding, a policy document, or an RFP response and have the reference still resolve in the future.

Filing an issue is a durable way to disagree with this. If a control is ineffective in practice, if we've missed one, or if implementing one costs more than the risk it removes, that's exactly the feedback the review period exists for. The goal is a single, vendor-agnostic model we can all start building toward and measuring ourselves against.

Check out the Agent Baseline, read the whitepaper, and comment on GitHub to contribute.