How Does Your Agent Know What It Can Do?

Zero Trust was right.

“Never trust, always verify” is one of the few security ideas of the last decade that survived contact with reality. NIST SP 800-207 gave it a spec, enterprises rebuilt around it, and the implicit-trust perimeter is gone in most places that matter. None of what follows is an argument against any of that.

But Zero Trust answers one question — who is asking? — and then hands off. Verification establishes identity; everything downstream is enforcement. That division of labour worked for two decades because of an assumption nobody had to write down.

People know their own jobs.

Sarah in Finance does not need a system to tell her she is not supposed to approve her own expenses, or provision a user in a division she has never worked in. She knows the shape of her role. The system verifies she is Sarah, gives her a console, and relies on her understanding of her own authority to keep her inside it. Enforcement exists for the exceptions — for mistakes and for bad actors — not for the ordinary case.

An AI agent has none of that. It has no sense of its own job. It will attempt anything it believes is available to it, with complete confidence and no instinct that something might be beyond its remit.

Here is what it looks like when something does tell it. This is what one governed agent run returns — the persona that ran, the assertions that had to clear, the surface its authority resolved to, and a fingerprint tying the run back to the authority behind it. The rest of this piece is why each line is there.

The question everyone is now asking

The Cloud Security Alliance has been making the point directly. Agentic systems, it argues, are a distinct category that breaks several legacy assumptions — not static service accounts running fixed scripts, but autonomous entities that move between systems, reason about tasks, and take actions on behalf of users. Zero Trust’s first pillar was not designed for that. Correct, and overdue.

The question being asked alongside it is: what happens after the agent is verified?

It is a reasonable question, and it has produced a reasonable answer. Put something in the path. Intercept the call, evaluate it against policy, and block it if it falls outside the boundary. Log the attempt. That is roughly where the market is, and it is better than nothing by a wide margin.

It is the wrong question

An agent that has to be caught was never told.

Interception is a correction applied to an actor operating on bad information. It assumes the agent will try things it should not, because it has no way to know better — and then builds machinery to catch it in the act. That is a reasonable design if you accept the premise. The premise is what deserves examining.

The more useful question is:

How does the agent know what it can do next?

Agents literally ask this

This is not a metaphor. It is a protocol step.

When an agent connects to a tool server, the first thing it does is ask what tools exist. Tool discovery is an agent asking, in as many words, what is my job here? Everything it subsequently attempts is downstream of the answer it receives.

So the answer matters enormously — and the protocol is not what holds it back. MCP already supports a surface that changes: a server can declare its tool list dynamic, emit a notification when it changes, and the client re-fetches. The mechanism for answering this question properly is in the spec.

What almost every implementation does instead is answer with a fixed manifest. Somebody decided at design time what this agent should be able to do, wrote it down, and every instance of that agent — acting for anyone, in any context, at any time — receives the same list.

That list is a guess about the agent’s job. A good guess, sometimes a very good one. But it is not the agent’s authority, because authority is not a property of the agent. It is a property of the situation: who the agent is acting for, where in the organisation that puts it, and what that position actually permits right now.

Guesses also err generous, because nobody wants to be the person who under-scoped the agent. The tendency is not unique to tool manifests: according to the Cloud Security Alliance, roughly 99% of non-human identities hold permissions far beyond what their actual workloads require.

The gap between the guess and the truth is the entire problem. Interception exists to police that gap. It is a mechanism for catching an agent acting on information we gave it.

What changes when the answer is computed

Suppose the answer is not configured but derived — the tool surface computed from the authority model at the moment the agent asks.

Now the list the agent receives is not a guess. It is the actual set of things this actor, in this position, is entitled to do, right now. Which means the agent cannot attempt something out of scope, because it was never told such a thing exists. Out of scope is not denied. It is not there.

Nothing to enumerate. Nothing to probe. Nothing to block, because nothing out of bounds was ever offered.

This is a different primitive from interception, and it is worth naming once: containment. Not a stronger guard, but the removal of the gap the guard was compensating for.

Two consequences are worth sitting with. The first is that denial leaks information — an agent that gets refused has learned that something exists on the other side of the refusal, and an agent that can enumerate refusals can map a boundary it was never meant to see. Absence leaks nothing.

The second is subtler and matters more in practice. An agent working from a truthful surface does not need correcting. It is not being restrained; it is being informed. Most of the behaviour we currently call “agent misbehaviour” is an agent doing exactly what it was told it could do.

The uncomfortable part

If this is right, then a good deal of what is being built for agent security right now is compensating machinery — necessary only because the agent was handed a list nobody derived.

That is not an argument for removing the guardrails. Defence in depth is real and interception has a permanent place. It is an argument that the interesting work is one layer earlier, at the moment the agent asks what it can do, and that almost nobody is working there.

If you want the mechanics — how a tool surface gets derived, and what separates a governed one from a wrapper — the MCP maturity ladder covers it. For where this sits relative to the identity perimeter, Okta got the category right and this is the half that comes after. And if you want the architecture-level version of the argument, including why delegation chains do not solve it, that one is here.

The short version: stop asking what your agent will do. Ask how it knows.

IdentityRM computes an agent’s tool surface from a governed authority model at the moment it asks — so what an agent can see is what it is actually entitled to do. See how the platform works.