Every AI agent now has an identity. That is not the same as control.
Ask a security team how they are securing the AI agents their business is deploying and you will usually hear about identity. The agent gets a non-human identity, a service account, a token issued by the identity provider, an entry in the machine-identity inventory. The IAM vendors have moved fast here, and it shows: non-human identity is now a product category of its own, and most organisations deploying agents in 2026 can at least tell you which identity an agent authenticates as. On paper, the box is ticked: the agent can prove who it is.
But identity was never the thing that kept you safe. Identity is a name tag. It tells a system who is knocking. It says nothing about what that caller is allowed to do once the door opens, or how much of it, or whether anyone will be able to reconstruct what happened afterwards. For a human employee, that gap is filled by years of accumulated controls, review, and judgement. An AI agent has none of that, and it acts thousands of times faster.
The industry has started to name this gap precisely. OWASP’s Top 10 for Agentic Applications, published in late 2025, lists tool misuse and identity-and-privilege abuse as distinct top-tier risks — not because agents lack identities, but because an authenticated agent carries whatever privilege its credential holds into every action it takes. The principle OWASP lands on is least agency: grant an agent only the minimum autonomy required for a safe, bounded task. That is a problem of controlling and enforcing what an agent does, not of naming it — and it is the part most deployments still miss.
A concrete example: the support agent with a refunds button
Picture a customer-support AI agent. The business connects it to two systems it genuinely needs — the CRM, so it can look up a customer’s history, and the payments platform, so it can issue small goodwill refunds without a human in the loop. Wired up through an MCP server or a couple of tool definitions, this is now an ordinary build: an afternoon of integration work, not a platform project. (MCP brings its own version of this exact confusion — we have written before about why MCP authorization and agent identity are different questions.)
Now give that agent an identity and a credential to those two APIs, and stop there — which is where most deployments actually stop. From that moment, the agent can do anything those credentials can do. It can read every customer record in the CRM, not just the one it is helping. It can issue a refund for ten dollars, or for fifty thousand. It can hit an endpoint nobody expected it to touch, because a prompt-injected support ticket talked it into it — the same class of attack we covered in defending MCP servers against prompt injection — or because the model simply generated the wrong request. Every one of those failure modes has been demonstrated in the wild; none of them requires the agent’s identity to be compromised.
The identity is impeccable throughout. Every one of those calls is correctly attributed to the agent. That is precisely the problem: attribution is not restriction. Knowing exactly which agent drained the refunds account is not the same as stopping it.
Identity, authorization, control, and enforcement are four different jobs
It helps to separate four things that get collapsed into the word “auth”:
- Identity answers who is this? The agent proves it is the support agent and not something else.
- Authorization answers what is this caller allowed to do? Not “which API can it reach” but which specific operations on that API — read one account, issue a refund under a set amount, and nothing adjacent.
- Control answers what data actually flows through the call we allowed? An authorized call is not a harmless call. The agent may legitimately read an account record — but the response that comes back carries stored payment details, contact history, and internal notes the workflow never needed, and every one of those fields lands in the model’s context, where a prompt injection can ask for it by name. Control is the filtering and redaction layer that shapes the payload after authorization: strip the fields the agent has no business seeing, in both directions, before they move.
- Enforcement answers did we actually stop the call that broke the rule — on every system the agent touches? A policy that is written down but never checked at request time is documentation, not a safeguard. And the scope has to match reality. An agent’s ecosystem is heterogeneous: some of it is APIs you built and can add controls to, but most of it is SaaS platforms — the CRM, the payments provider, the ticketing system — whose permission models are whatever the vendor shipped and whose code you will never change. Enforcement that only works on the systems you develop covers a shrinking fraction of what your agents actually call.
Identity providers are built for the first job and, increasingly, part of the second — they can issue scoped tokens and hold policy. The last two are the missing pieces. No token can redact a field out of an API response, and no policy document can refuse a request at the moment the model generates it. Both jobs require something sitting on the wire, evaluating every individual outbound call and its payload in real time. And that something has to live on the one segment of the path you actually control — the outbound side — because the upstream usually is not yours to modify. You cannot patch a policy engine into a vendor’s SaaS platform, and you cannot wait for every provider in the ecosystem to expose permissions fine-grained enough for agents. That is a different location in the architecture and a different job. The emerging consensus — visible in everything from the OWASP agentic guidance to the Cloud Security Alliance’s work on non-human identity governance — is that this point has to live outside the agent’s reasoning loop. An agent cannot be trusted to police itself, because the thing you are defending against is the agent’s own output.
The governance clock is now running
For the first two years of the agent era, runtime enforcement was a best practice you could defer. That window is closing.
The EU AI Act’s obligations for high-risk AI systems are currently scheduled to apply from August 2026 (the Commission has proposed some timeline adjustments while harmonised standards are finalised, but the direction is fixed). For systems in scope, Article 9 requires operating risk management — not a one-off assessment — and Article 12 requires automatic logging sufficient to reconstruct what the system did over its lifetime. ISO/IEC 42001 certification, which enterprise buyers increasingly ask for, requires that AI controls exist, are documented, and are auditable. And in February 2026, NIST launched its AI Agent Standards Initiative — an explicit signal that regulators view autonomous agents as a governance problem existing frameworks only partially cover.
Read those requirements against an agent deployment that consists of “an identity and a credential” and the gap is stark. You cannot demonstrate risk mitigation with an architecture that observes what an agent did after the fact. You cannot produce a lifetime audit trail from partial application logs scattered across agent frameworks. A deterministic control point in front of the agent’s API access is quickly becoming the cheapest honest answer to both.
Why the token can’t stop the refund
The reason identity alone leaves the gap open is timing and placement. A token is issued once, up front, and it is coarse by design. It might say “this agent may use the payments API.” It does not — cannot practically — say “this agent may issue refunds up to $100 against orders it has already looked up, and may not touch payouts at all,” and then be present at the exact instant each of those calls is made to make the decision stick.
Enforcement has to happen where and when the call happens: on the outbound request itself, at runtime, every time. If the check lives anywhere else — in the token, in the agent’s own code, in a policy document a team promises to follow — then the moment the model does something unexpected, there is nothing between it and the upstream API. And the entire reason we are nervous about agents is that they do unexpected things.
What moves when enforcement moves to runtime
Runtime enforcement means putting a control point between your agents and the APIs they call, and making every call pass through it — a gateway the agent calls instead of calling the API directly. Because the control point sits on the outbound path, it applies one policy model to everything downstream of it: the same rule syntax governs your own services and the SaaS platforms you could never modify, regardless of how coarse each vendor’s native permissions are. Five things change immediately.
The agent starts with nothing. The control point denies by default, so the agent can call nothing at all until you explicitly grant an operation. You then allow exactly what the workflow needs. For the support agent, that is “read a single account” and “issue a refund below the threshold” — expressed as rules that are checked before any call is forwarded:
{
"effect": "allow",
"ruleActive": true,
"methods": ["GET"],
"path": {
"path": { "pattern": "^/v1/accounts/[^/]+$" },
"presence": "must_exist"
},
"notes": "Support agent may read a single account record"
}Everything not on the allow-list is refused at the gateway, regardless of what the model decides to generate. This is also what fail-closed looks like in practice: the safe state is “no call goes through,” not “the agent proceeds unchecked.” Be clear-eyed about what that costs — the control point is now part of the critical path, and if it is unreachable, agent workflows stop. For autonomous traffic that is the correct default; a paused agent is an incident, an unchecked one is a breach. Least agency stops being an aspiration about model behaviour and becomes an enforced boundary.
The agent sees only the data it needs. Allowing the call is not the end of the decision — the control point also filters the payload. On the way back from the CRM, the account record can be reduced to the fields the workflow actually uses: destroy the stored payment details and internal notes, retain the name, status, and order history. The model’s context only ever contains what survived the filter, so a manipulated prompt cannot exfiltrate a field the agent never received. The same applies outbound, where request bodies can be constrained before they reach the upstream API.
The agent never holds the real credential. The agent authenticates to the control point with one managed credential; the gateway holds the actual CRM and payments secrets in a vault and attaches them only when it forwards an approved call. The keys to your production systems never live in the agent’s configuration, its logs, or its model context — so a verbose log or a leaked context window has nothing to give away — and you revoke or rotate access in one place without touching the agent.
Every call leaves a record. Because all traffic flows through the control point, each request — method, path, outcome, timing, and which rules it was checked against — is logged in one place. When the compliance team asks what the agent did with the payments API last Tuesday, or an auditor asks you to demonstrate the logging a lifetime audit trail requires, the answer is a query, not a forensic reconstruction from partial logs across three agent frameworks.
Shadow agents surface themselves. Every survey of security leaders this year says the same thing: the agents you know about are not the problem — the ones a team wired up last quarter without telling anyone are. A discovery programme chases that sprawl after the fact. An egress control point inverts it. Once the sanctioned path to an upstream API runs through the gateway — and the upstream credential is rotated so only the gateway holds a working key — anything still calling that API directly identifies itself by failing. Unknown agents stop being invisible; they become a short list of broken integrations whose owners come to you.
One more thing this architecture does that matters to anyone rationalising a security stack: it consolidates rather than adds. Per-agent secret storage, per-vendor permission workarounds, per-framework audit logging, and rate limiting each stop being separate problems with separate tools — they are all properties of the one control point the traffic already flows through.
The limits worth naming
This is not an argument that identity work is wasted — it is the foundation, and runtime enforcement depends on knowing who the caller is. And there are cases where issuing an identity and stopping there is a reasonable risk decision: an agent confined to a read-only, non-sensitive, internal data source; a proof of concept that never touches production; a system where a blast radius of “everything the credential can reach” is genuinely acceptable.
Runtime rules have a limit worth naming honestly too. They evaluate each call on its own, and a chain of individually permissible calls can still add up to something you never intended — reading one account is allowed, so reading ten thousand accounts one at a time is ten thousand allowed calls. The per-call answer to that is volume, not semantics: metering the proxy caps how many requests an agent can make in a window, so a runaway loop or a slow-drip extraction hits a ceiling instead of running to completion (rate limiting on the same control point covers this in depth). Detecting intent across a chain of calls remains a monitoring problem that no per-request control fully solves — which is one more reason the audit trail matters.
The judgement call is simple to state. If the honest answer to “what is the worst this agent could do with the access we have handed it?” is something you would not sign off on happening automatically, then identity is not your control. Enforcement on the call is.
Next steps
Start by writing down, for one real agent, the shortest possible list of operations it actually needs — that list is your allow-list, and it is usually shorter than anyone expects. Then stand up a deny-by-default control point in front of the APIs it calls and grant exactly those operations before you connect anything.
This is the job RequestRocket was built for: runtime access control over the APIs you don’t own as much as the ones you do. Every agent call gets a least-privilege credential, a policy check, payload filtering, and an audit record, with no changes to the agent’s code or the upstream system — the rule shown above is a live proxy rule, not pseudocode. Read the documentation for the full proxy, credential, and rule reference, or start for free.