Intelligence without access is a demo; access without control is a breach. Almost every enterprise AI conversation starts in the first state and gets stuck before the second. The model is impressive, the workflow is automated, the task that took hours takes minutes — and then someone asks what it is actually allowed to do in production, and the room goes quiet. The uncomfortable truth is that most organisations are still treating AI as a model problem when it is rapidly becoming an identity problem. The first AI problem is intelligence. The second — the one that decides whether any of it reaches production — is identity.
The first AI problem is intelligence. The second is identity.
The demo and the second conversation
The pattern is so consistent it is almost a law. The first conversation is a triumph; the second is where it gets hard — because the second conversation is about access. Can it update a record? Approve a transaction? Trigger a workflow? Reach customer data? And if it does, with whose permissions, under what authority, and how would anyone prove afterwards what it did? At that moment the discussion moves, irreversibly, from intelligence to access — and the teams that get past it stop trying to make the model trustworthy and start engineering what it is allowed to touch.
Your biggest identity problem is no longer human
For thirty years, identity meant people — employees, contractors, customers — and access management was built around them. That assumption is now wrong. Machine identities already outnumber human ones by something like eighty to one (the exact ratio varies wildly by how you count, but every serious estimate points the same way and steeply upward), a large share of them hold privileged access, and AI is now the single biggest driver of new privileged identities. An agent is not a feature of a system; it is a new actor in it — and so are the services, workflows and tools it calls. Identity is no longer humans. It is humans plus services plus agents plus workflows plus autonomous systems, and the population you never managed is the one growing fastest. The unnerving part is how few organisations have noticed: by one 2025 survey only about a tenth have a developed strategy for governing non-human identity at all.
How access becomes breach
Give a capable agent broad, standing access and you have not built a product; you have built a blast radius. The failure modes are now well catalogued. Prompt injection turns an agent’s access into someone else’s instructions — a malicious string in a document or a web page becoming a command executed with the agent’s permissions. Excessive agency — too much functionality, too many permissions, too much autonomy — means an unexpected or manipulated output causes real damage because nothing constrained what the agent could do. The confused deputy problem means an over-privileged agent is tricked into using its authority on someone else’s behalf. And underneath it all sits the oldest mistake, now at machine scale: borrowed and standing credentials, hardcoded keys, secrets sprawled across configs. The lesson compresses to a single design fact: every permission granted to an agent is an architectural decision, whether you treated it as one or not.
The answer the standards already wrote
The encouraging news is that the hard thinking is largely done; it just has not been built. The OWASP guidance for LLM applications already prescribes the doctrine: least privilege, authorization carried in the user’s context rather than a borrowed, over-privileged token, and human-in-the-loop approval for high-impact actions. The Model Context Protocol encodes the same discipline into the wire: servers act as proper OAuth resource servers, tokens must be audience-bound to the server they were issued for, passing a token through to a downstream service is explicitly forbidden (precisely to defeat the confused deputy), consent is per-client, and scopes are minimised. The gap in most enterprises is not knowledge of what good looks like. It is that nobody has built the place where all of it is enforced.
The Agent Gateway
That place is the Agent Gateway: the brokered control point an agent passes through to act on anything that matters, where both the value and the safety of agentic systems concentrate. It is not a firewall bolted on afterwards; it is an architecture, with three components:
- Scoped Identity — every agent gets its own non-human identity with least privilege and short-lived, brokered credentials, never a borrowed human token or a standing key in a config.
- Action-Level Authorization — permission is checked per action, in the user’s context, with human-in-the-loop approval for high-impact operations and audience-bound tokens that cannot be passed through (the confused-deputy defence).
- Audit & Reversibility — every action the agent takes is logged in a form a human can read on a bad day, and designed so it can be withdrawn, reversed or halted.
Least Agency
The principle that runs the gateway is the deliberate inverse of OWASP’s “excessive agency”: Least Agency. Give an agent the minimum it needs to do the task in front of it, brokered and logged, reversible by default — and widen that only on evidence, the way you would extend trust to a new hire, not all at once on day one. The teams that get this right design the boundaries before they expand the access: they assume the agent will be wrong, and build for recovery first. The teams that get it wrong treat safeguards as something to add later, once the value is proven — by which point the access is already broad and the difficult decisions have become urgent.
The most revealing question was never what the agent could do — it was what happened when it was wrong. Could the action be reversed? Could access be withdrawn? Could a human intervene? The strongest teams designed those answers before they expanded access; the ones that struggled treated safeguards as something to add later — by which time the hard decisions had already become urgent.
| Pillar | What it governs | Without it |
|---|---|---|
| Scoped identity | Who or what the agent is — a narrow, per-task identity | A shared, over-privileged credential nobody can trace |
| Action-level authorization | What each call may do — allow / deny / ask, per action | Excessive agency: it can do anything it can reach |
| Audit & reversibility | A record of who decided what — and the ability to undo | A breach you can neither reconstruct nor stop |
Decisions and actions are the same discipline
This is the runtime twin of a governance idea. Decision Architecture determines who is allowed to decide; the Agent Gateway determines what those decisions are allowed to do. One assigns rights, gates and reversibility to human and organisational decisions; the other assigns identity, authorization and reversibility to agent actions. They are the same discipline pointed at two layers — and an organisation that governs its decisions but not its agents’ access has simply moved the ungoverned risk one layer down. Govern both, or you govern neither.
Which reframes the whole race. The question is no longer whether an agent is intelligent enough to act. The question is whether your organisation is disciplined enough to let it. The winners in enterprise AI will not be the ones with the cleverest agents; they will be the ones who built the gateway that lets a capable agent act on real systems without becoming the breach. The intelligence was never the hard part. The access was.
Frequently asked
- Why do capable AI agents stall in the enterprise?
- Usually not because the model is inadequate, but because giving it safe, scoped access to production systems is unsolved. The blocker is identity, authorization and accountability — what the agent is allowed to touch and whether you can prove what it did — not raw capability.
- What is the Agent Gateway?
- The brokered control point an agent passes through to act on real systems, with three components: Scoped Identity (its own least-privilege, short-lived credentials), Action-Level Authorization (permission per action, in-context, human-in-the-loop for high-impact, audience-bound tokens), and Audit & Reversibility (every action logged and reversible). It is where the value and the safety of agentic systems concentrate.
- What is the biggest agent security risk?
- Excessive agency combined with prompt injection: an over-permissioned agent whose access becomes someone else’s instructions. The defences are least privilege, per-action authorization, audience-bound tokens (no passthrough — the confused-deputy defence) and human-in-the-loop on high-impact actions, as OWASP and the MCP spec prescribe.
- How should an agent authenticate to systems?
- With its own non-human identity and least privilege, using short-lived, brokered credentials — never a borrowed human token or a standing key in a config. Non-human identities now vastly outnumber human ones and are the fastest-growing, least-governed part of the estate.
- How is this different from securing AI-generated code?
- That is build-time: the quality and security of code an AI writes. This is runtime: what an agent is allowed to do once it is live. A perfectly reviewed agent with a borrowed, over-privileged token is still a breach waiting to happen.