Your AI agent passed security. That doesn't mean it's safe.
Most companies bolt on security after their AI agents are already running. A new analysis of real deployments shows why that order gets people into serious trouble.
Key points
- In June 2025, the US cybersecurity agency CISA added a flaw in LiteLLM, a popular AI traffic management tool, to its list of actively exploited security holes.
- That single tool had seven separate security flaws disclosed in one month, and one required no password at all to exploit.
- A 2026 study of 205 security leaders found that organisations with overly broad AI access reported a 76% incident rate, compared with 17% at those that kept access tight.
- Security expert analysis of real deployments shows that most companies apply enforcement controls too early, before the basic identity plumbing is in place.
- A six-step framework called dependency-gated deployment puts identity and attribution first, and runtime enforcement fifth.
Imagine hiring a contractor and handing them a master key on day one, before you have written down what rooms they are allowed to enter, whose authority covers them, or what job they were sent to do. That is roughly what most companies do when they deploy AI agents.
An AI agent is software that can carry out multi-step tasks on its own, reading files, calling databases, sending requests, sometimes spending money. Companies are deploying them fast. The security tends to come second.
What went wrong with the gateway approach?
The first thing most security teams reach for is a gateway, a piece of software that sits between the agent and the systems it talks to, checking each request like a bouncer at a door. The problem: the bouncer only checks the ID on the card, not whether the person holding it is allowed to do what they are actually trying to do.
In June 2025, CISA, the US Cybersecurity and Infrastructure Security Agency, flagged a serious flaw in LiteLLM, a widely used gateway tool, after attackers were caught exploiting it in real attacks. The bug let an attacker run commands directly on the server. Chained with a second flaw, it needed no password at all. That was one of seven security flaws disclosed in LiteLLM in a single month.
A gateway that is itself vulnerable is a poor first line of defence.
What should companies do instead?
Security analysis of production deployments points to a six-step order. Skipping ahead causes the failures.
| Gate | Control | What proves it works |
|---|---|---|
| 1 | Agent inventory and ownership | Every agent has a named owner and stated purpose |
| 2 | Distinct agent identity and delegation | The system knows which agent acted and who authorised it |
| 3 | Task-scoped, short-lived credentials | A compromised agent cannot reach systems outside its job |
| 4 | Attributable logs | A completed task can be reconstructed start to finish |
| 5 | Runtime action enforcement | The gateway checks agent, principal, task, and resource together |
| 6 | Behavioural baselines and kill switch | The agent's authority can be cut everywhere it reaches |
The core insight is simple. A valid login token proves someone had access. It does not prove the agent was supposed to do what it just did, or that the person whose token it borrowed ever authorised that specific action.
Twenty agents can run under one employee's permissions and still need separate identities, separate logs, and separate ways to revoke access. Sharing a token does not share accountability.
Why does the order matter so much?
Access scope matters more than clever runtime controls. The 2026 Teleport study of 205 security leaders found that organisations with over-privileged AI agents, meaning agents with broader access than their job required, reported a 76% incident rate. Organisations that kept access tight reported 17%.
The principle the framework calls monotonic delegation means every hand-off of responsibility must preserve or reduce authority, never increase it. A finance reconciliation agent should be able to view one ledger, not inherit the full access of the employee whose token it is using.
Gateway enforcement should come fifth in that chain, not first. By that point it has real context: a registered agent identity, an explicit delegation record, scoped short-lived credentials, and a complete audit trail. Then it can ask a meaningful question: is this agent authorised to take this specific action, for this specific person, in this specific task? That is the question that matters at irreversible moments like payments, deletions, or changes to production systems.
First, though, you have to be able to name every agent you are running.
