Your AI Agent Has More Permissions Than Your Intern. And No One Gave It a Contract.

I have spent more than ten years working in security and identity, and lately there is a scene that repeats itself in almost every conversation with teams deploying AI agents into production. Someone shows an impressive demo: the agent reads email, queries the database, cross-references the data, generates the report, and sends it to the correct recipient. Well-deserved applause, because the demo is usually excellent. And then I ask what credentials it used to do all of that.

Silence. The answer, when it comes, is usually some variation of “the user’s” or “an API key we put in the config at the start and it is still there.” The agent has inherited a person’s full identity, or is carrying a secret created months ago that no one has rotated since. It works, of course it works. Leaving the key under the doormat worked too.

I want to dedicate this article to explaining why what works is a time bomb, what architecture defuses it, and where I would start tomorrow if I had to fix it in a real organization, with its twenty-year-old corporate directory and its teams that have already deployed agents without waiting for security to give them permission.

Old problems, new actor

Those of us from the IAM world know the concept of standing access all too well: permissions that exist permanently, whether used or not. We have spent years fighting to reduce them on human identities, with mixed results, entitlement reviews approved in bulk on a Friday afternoon, and recertifications that no one reads. All of that is old. What has changed is who exercises those permissions.

With humans, there was a mitigating factor that never appeared on the risk board, although we all silently relied on it: an employee with excess permissions rarely discovers them. They almost never know they can read that finance folder they were given access to by mistake in 2019, and even if they did, they have better things to do. Obscurity acted as a compensating control. None of us likes to admit it out loud, but half the IAM industry has lived comfortably on that assumption for two decades.

An AI agent demolishes that assumption on the first task you give it. An agent traverses its permissions, tests them, chains them, and exhausts them, at machine speed, every time the objective you set requires it. If you asked it to “get me all the relevant data for this report” and it has excess access, it will use the excess access, with the best of intentions, because that is what you trained it to do.

And there is a second difference that strikes me as even more serious than the first. In a traditional application, the logic that decides what to do with an input is deterministic code. Someone wrote it, someone reviewed it, someone tested it, and it has a finite number of paths that can be audited. In an agent, the decision layer is a language model interpreting text. Any text. The document you asked it to summarize. The web page it consulted to verify a fact. The email from a third party it read because it was in the thread. Each of those texts can contain instructions directed at the model, and the model, by design, is trained to follow instructions.

This has had a name in the security literature since the 1980s: the confused deputy problem. A component with more privileges than the party requesting an action ends up misusing them because someone confused it. The canonical example was a compiler with write permission on a protected file, tricked through a malicious file name. Forty years later, the deputy is an LLM, and the manipulation now travels hidden in any paragraph of natural language the agent processes during its workday. The problem is venerable. The attack surface is new, and it is enormous.

Let us do the damage calculation

In security, we use the term blast radius to talk about how much damage a compromised identity can cause. It is worth doing the calculation carefully for the typical agent deployment I am seeing enter production this year.

Starting point: an agent with a user’s full session context, plus a long-lived API key for systems that do not support anything else. The incident arrives, in the form of a prompt injection hidden in a PDF the agent processes on any given Tuesday. What does the attacker have from that moment on?

They have all of that person’s permissions, exercised with the tireless diligence of a machine. They have credentials that will remain valid for weeks or months after the incident, because no one rotates them, and that have probably already been copied somewhere from which to reuse them at leisure. And they have something that, as someone responsible for incident response, keeps me up at night: logs that say the legitimate user did everything. Because the agent acted with their session, and no record in any system shows that there was an intermediary. Forensics will point to an innocent person, and the organization will take days just to understand what happened.

Let us contrast this with the scenario I defend in the rest of the article. The same malicious PDF, the same Tuesday. But the agent operates with a token issued for that specific task, with a read-only scope on a single system, with an audience that makes the token useless against any other destination, and with a five-minute lifespan. The token also records two identities: the user on whose behalf the action is taken and the agent materially executing it. The attacker gets, at worst, a few minutes of read access on a bounded system, with the entire delegation chain written into every record. The incident is investigated in a morning and the forensic report tells the truth.

The difference between the two scenarios is not determined by luck or the attacker’s skill. It is determined by the architecture underneath.

Five layers, because each covers what the others structurally ignore

When I explain this, the usual reaction is to ask me what product fixes it. I understand the question, the market is full of vendors delighted to answer it, and some of those tools are good. But after spending years on both sides of that commercial conversation, my honest answer is that there is an architectural model to build here, and the tools come later, once you know which layer each one covers. Here are the five layers, from inside out, dwelling on each one enough to understand which specific threat it addresses.

Layer 1 — The execution sandbox. When an agent needs to run code, that execution happens in an ephemeral container created for that task and destroyed when it finishes. Inside the container: network egress closed except to explicitly allowed destinations, read-only filesystem except for a temporary working directory, CPU, memory, and time limits, and no long-lived credentials baked into the image. That last point deserves emphasis, because it is the mistake I see most often: impeccably isolated containers with an eternal API key inside an environment variable. If the isolation falls, the attacker walks away with a secret that still works outside. Candidate technologies for this layer: gVisor, Firecracker, native Kubernetes policies. What this layer contains is the local blast radius, what the agent can touch on its own machine when something goes wrong.

Layer 2 — Identity and delegation. The heart of the model, and the ground where those of us from IAM have the most to contribute. I build it on three design decisions.

First decision: the agent never stores its own secret for authentication. It uses the identity its execution platform already provides and attests to — a Kubernetes service account, a cloud workload identity — and exchanges it with the identity provider for a short-lived token. It sounds like a minor detail and it changes the whole game, because it eliminates the problem of distributing the first secret. If there is no bootstrap secret, there is no bootstrap secret to leak in a repository, a log, or an image.

Second decision: the token the agent receives is not the user’s session, it is a reduced derivative of it. Scope limited to the permissions the specific task needs, not one more. Audience restricted to a single target system, so that the token, if intercepted, is useless against any other service in the organization. Lifespan in minutes, calibrated to the expected task duration. The formal mechanism to produce that derivative exists and has been standardized for years, the token exchange of RFC 8693, and it still surprises me how little it is implemented.

Third decision, the one that separates those who have thought about the day after the incident from those who have not: the token carries two identities simultaneously. The subject field says on whose behalf the action is taken, and the actor claim says who is materially acting. With that, every downstream system that receives a call from the agent knows, and records, that it was agent X operating on delegation from user Y. Without that, we are back to forensics pointing at innocent people.

The real world remains, where half the enterprise runs on systems that do not speak modern identity protocols. A database wants a username and password, not a token with claims. For that world, a dynamic secrets manager acts as translator: the agent presents its token, and the manager fabricates on the fly a temporary credential — a database user born for that task and dying with it — whose lifespan inherits the brevity of the token that originated it. Candidate technologies for this entire layer: Keycloak, Okta, or Entra ID on the identity plane; Vault or Conjur on the dynamic secrets plane.

Layer 3 — Standardized tool access. Imagine that each team in the organization connects its agents to internal tools however they can: one with direct REST calls, another with a homegrown SDK, a third with something they found on GitHub. The result is fifteen different security postures, each with its own way of authenticating, limiting, and logging — or forgetting all three. The alternative is a single tool access protocol, and MCP is consolidating as the de facto industry standard, with a growing ecosystem of commercial and open-source gateways that add what the protocol deliberately leaves out: per-call authentication, per-tool scope verification, audit logging. With that layer in place, the security model is applied once, at the interface, and it does not matter which orchestration framework each team chose to build their agent. That separation also has an organizational virtue I value highly: it allows standardizing tool access without legislating which agent technology everyone uses, which is a battle no platform team should want to fight.

Layer 4 — Intent guardrails. I arrive at the lesson that cost me the most to digest coming from the identity world, and I illustrate it with the scenario I always use. An agent carries a technically perfect token: minimum scope, single audience, five-minute lifespan, actor claim in place. An attacker slips in a prompt injection, and the agent calls an endpoint it is legitimately authorized to reach, with malicious parameters dictated by the attacker. Did the token fail? None of its controls failed. The token answers the question of whether that call is authorized, and it was. The question no one was asking was whether that specific call, with those specific parameters, made sense.

Validating sense, validating intent, is a different function from validating permissions, and it requires its own layer between the agent’s decision and the execution of the action. In practice, it combines three mechanisms: validation of call content against explicit rules, policies expressed in natural language that another model evaluates before letting the action through, and mandatory human approval for anything exceeding a certain risk or irreversibility threshold. I call this layer soft with full intention, because one model evaluating another can be wrong, and it is wise to design knowing that. But it covers a gap that no amount of permission engineering will ever close, because permissions speak about what can be done and this layer speaks about what should be done.

Layer 5 — Telemetry and risk feedback. Every token issuance, every dynamic credential generated, every tool call, every guardrail decision, recorded at a central point with common correlation fields. I insist on correlation fields because they are what turn a pile of logs into a possible investigation: a unique token identifier that links the issuance event at the identity provider with the corresponding call at the target system, the subject and actor claims to know who acted and on whose behalf, and a reference to the task that originated everything. With that, you reconstruct what happened six months later, without depending on anyone’s memory.

On top of that telemetry sits the part I find most elegant in the entire model. A behavioral baseline is built per agent — what it calls, how often, at what times, with what scopes — and deviations become risk signals. And that signal travels back to the identity layer: the agent that deviates from its pattern receives its next credential with a shorter lifespan, narrower scope, or directly with a human in front approving. Detection stops being a report someone reads on Monday and becomes an input to the credential issuance system itself. Candidate technologies: any serious SIEM, Splunk, Sentinel, or QRadar, with OpenTelemetry-style instrumentation feeding it.

The design assumption that orders everything else

The entire model above derives from a single starting assumption, and I prefer to make it explicit: the agent will be deceived, sooner or later, and the architecture decides how much it costs each time it happens.

Perimeter security went through its own grief with “assume breach” years ago. It was hard to accept, there was resistance, and today no serious professional designs a network assuming the perimeter will hold indefinitely. Agentic systems face the same grief, and the sooner we go through it, the better. Prompt injection has resisted a definitive solution for years, and everything points to it staying that way, because asking a language model to follow instructions while simultaneously ignoring malicious instructions is asking it to distinguish something that often even a human does not distinguish at first glance. Designing under the assumption that deception will occur shifts the effort toward where we do have control: so that a deceived agent, during the five-minute lifespan of its credential, confined to one system, with anything irreversible behind human approval, is a minor incident investigated in a morning with complete logs. That outcome is achievable with the engineering we already know how to do.

The twenty-year-old directory

Before talking about where to start, I want to defuse the objection I always hear in large organizations, because it is legitimate and has a solution. The objection goes: all of this sounds great, but our Active Directory has twenty years of history, nested groups inside nested groups, email distribution lists acting as permission groups because someone thought it was practical in 2011, and service accounts no one dares touch because no one knows what would stop working. Cleaning that up would take years.

It would take years, yes. And the good news is that prior cleanup is unnecessary. The legacy directory is federated as an authentication source: people keep logging in with their usual account, with their usual corporate MFA, and no one migrates users anywhere. The new authorization model, the one for agents and their scoped tokens, is built cleanly in a separate layer, where directory group membership functions as one signal among several when evaluating a policy, rather than as the absolute source of truth. A policy can say that a given permission is granted if the user belongs to a given directory group, and it is business hours, and the request is scoped to their department. The group provides information; the decision lives in the new policy, which is documented, versioned, and audited. Directory cleanup thus becomes a background task that progresses at its own pace, while everything new is born with the correct model from day one.

Where I would start tomorrow

The mistake I have seen kill more initiatives of this kind, and I speak from experience because I have sat in both chairs: starting with an exhaustive six-month assessment of the entire agent fleet, all systems, all legacy. That project accumulates scope until it dies of it, produces an excellent document that ages in a shared folder, and meanwhile teams keep deploying agents without governance, because the business is pressing and no one is going to wait for security to finish its study.

My alternative fits in a phrase from military vocabulary: a beachhead. A single use case, deliberately small, deliberately boring. A read-only agent. An internal user delegating. A non-critical reporting system as the target. Mandatory human approval in the first version, even if it gets in the way, precisely to learn when it gets in the way. And the full five-layer model applied end to end to that tiny case: its sandbox, its token with actor claim, its dynamic credential if it touches a legacy system, its guardrail, its correlated telemetry.

When that beachhead works, and it will because it is small, it gets packaged. Ideally as an infrastructure-as-code module that any team can consume in self-service: you request an agent identity by filling in four parameters, the module creates the client in the identity provider, the minimum scopes, the token exchange policy, and the telemetry registration, and the security barriers live inside the module itself, which simply lacks a parameter for requesting a token lifespan longer than the maximum or a universal write scope. From there, adoption is won through convenience. If integrating the right way takes ten minutes with everything well done, and going rogue takes two weeks and three tickets, the cultural battle ends before it starts, and the corporate mandate remains as a last resort for the cases convenience alone does not carry. I have dedicated a good part of my career to the adoption of security services in large organizations, and if I have learned anything, it is that the standards that survive are those that win by being better, and those imposed by decree end up surrounded by exceptions.

The next chapter of a story we already know

There is a narrative going around that agent security is a new discipline that requires forgetting everything before it and hiring profiles that do not exist. My reading, after two decades in identity, goes in the opposite direction. Least privilege, just-in-time access, identity lifecycle governance, action attribution: the entire conceptual toolkit has been invented for years, and a good part of the technical toolkit too, starting with standards that lay half-forgotten waiting for their use case. What has appeared is a new population of identities that are created and destroyed in seconds, exercise their permissions without rest, and can be manipulated with a well-hidden paragraph of text. A population for which the classic toolkit, applied without adaptation, falls short, and applied with thought, fits.

Agents are already inside organizations, with governance or without it. I would rather dedicate these years to making sure they come through the front door, with their contract and their fair permissions, and that the first serious incident catches us with the architecture built and the logs complete, rather than turning into urgent what today can still simply be important.

---

If this problem is already on your desk, or you suspect it is about to be even though no one has put it in writing yet, I am interested in the conversation.

Francisco Oteiza Lacalle