Somewhere right now, a developer is creating a database user for a new web app. That database user gets broad access – most tables, full CRUD. Then that same broad credential gets handed straight to the app itself.
Few people would consider that architecture unusual. It has been standard practice for decades.
Now picture handing that identical credential to an AI agent instead of a web app. Suddenly it feels reckless. Same broad grant, same “one credential, many permissions” model – so why does one feel routine and the other like an obvious security risk?
The easy answer is “because agents are unpredictable and web apps aren’t.” That’s true, but it stops short of identifying what specifically broke. It treats nondeterminism as a general property of AI rather than an architectural change with security consequences.The more useful answer is about where the authorization decision actually gets enforced, and what changed there.
The Old Way: The Credential Wasn’t the Only Gate
In a traditional web app, the database grant is really just plumbing. The actual authorization decision – what a given end user can see, edit, or delete – is enforced somewhere else entirely: the app’s own authorization layer. Roles, permission checks, middleware, an if user.can_edit(record) buried in the request handler.
That authorization logic is implemented in code, reviewed, and deployed. Given the same inputs and system state, it is designed to enforce the same rule consistently.
That’s the assumption behind “one broad DB user is fine”: broad credential, plus a narrow and deterministic gate standing in front of it. The gate doesn’t improvise. It doesn’t have good days and bad days. Given the same request and the same role, it enforces the same rule, every single time. That reliability is what makes the broad grant tolerable. It’s not that nobody thought about security – it’s that the risk was absorbed by a component everyone trusted to behave consistently.
Why That Assumption Breaks for Agents
Agentic AI expert Ken Huang’s recent writing on agent gateways makes this concrete with a procurement example.
An agent is asked to summarize a supplier’s performance and draft a renewal recommendation. To do that job legitimately, it needs to read contract metadata, query delivery metrics, retrieve approved policy documents, and write a draft. It does not need — ever — the authority to modify the supplier’s bank account. But if that agent is holding one broad procurement-administrator credential for the whole session, the system has already granted every possible action before the agent has decided which action it’s actually going to take.
Here’s the part that matters: The “gate” in that architecture isn’t fixed code anymore. It’s the model’s reasoning, generated fresh on every turn, choosing which tool to call next. That’s the exact component that used to be deterministic in the old way, and it isn’t one anymore. Nothing about the credential changed. What changed is what’s standing behind it.
OWASP’s Top 10 for LLM Applications calls this “excessive agency,” which moved up sharply in the 2026 edition. The OWASP Top 10 for Agentic AI narrows it further into its own category: Identity and Privilege Abuse.
The same failure also maps to the classic “confused deputy” problem: a trusted intermediary tricked into misusing privileges it legitimately holds. MCP tool servers hit this at the connection layer too – approving a server typically grants every tool it exposes, not the one action a task actually needs.
Guardrails Don’t Put the Gate Back
You can try to constrain this with instructions in the system prompt. That can reduce risk, but it is not an authorization control.
But as anyone who’s spent time with these systems knows, the LLM can still decide to go straight through those guardrails, especially under adversarial input.
That’s not a bug you can prompt your way out of. It’s the mechanical difference between the two systems. Fixed app code cannot choose to skip its own if statement. An LLM can produce behavior that conflicts with its instructions, particularly when exposed to adversarial or conflicting input.
There’s a line making the rounds in MCP security circles that captures this well: A token is not a policy engine. A credential being valid tells you nothing about whether this specific action, right now, is the one that should happen.
The New Way: Move the Decision to the Point of Action
The fix is moving the authorization decision to where the old deterministic gate used to sit: right before each action executes. Per-action authorization evaluates agent identity, user, resource, action, and context at the moment a specific tool call is requested. get_delivery_metrics and update_payment_instructions become two separate policy decisions, not two things the same broadly-privileged session happens to do.
Security architecture has moved in this direction before. BeyondCorp challenged the idea that network location alone should confer trust, while OAuth has continued adding protections around how credentials are issued and used. Agents create another version of the same problem: authorization established earlier is not necessarily sufficient for the action being attempted now.
Concretely, that means moving away from a single standing credential toward access granted for the specific interaction, backed where appropriate by short-lived credentials and policy evaluated at runtime.
The Authorization Assumption That No Longer Holds
“Agents aren’t deterministic” is true but incomplete. The more telling version is that the component that used to guarantee determinism – fixed, reviewed, unchanging app code – has been replaced by live model reasoning, and the authorization architecture built around the old component doesn’t transfer.
So look at wherever your own agent is holding a broad, standing credential today, and ask what’s actually in front of it.
Is it still a deterministic gate? Or is it a guardrail an agent could talk its way past?
