The Blank-Check Problem: How Agents Inherit Authority

The blank-check problem is what happens when an AI agent starts acting under authority it never earned: a service account's credentials, an API key pulled from a vault, or a human's active session, borrowed rather than issued, and valid the instant the agent runs. Every agent inherits someone's trust; none arrives with authority of its own. "What Is Agentic AI Security?" named this as one of three questions security teams have to answer — who does each agent act as — and called an unscoped answer a blank check with a user interface. This piece is about why that inheritance happens so casually, why a shared credential makes it impossible to answer who actually acted once something goes wrong, and what it takes to stop treating both as a footnote instead of the design question they actually are.

Nobody designs the inheritance, it just happens

A service account gets created for a script, and six months later an agent is calling it because the credential was already sitting in the environment and reusing it was faster than provisioning something new. An API key scoped for one integration ends up injected into an agent's config because both needed a token and only one token existed. A human kicks off an agent from their own logged-in session, and the agent inherits every permission that session carries for as long as it runs. None of these are attacks. Each one is the reasonable, unremarkable choice an engineer makes under a deadline, and each one hands the agent authority nobody explicitly decided it should have.

The identity check that matters isn't "did this agent authenticate." It's "what did it authenticate as, and did anyone actually mean to grant that."

Shared credentials erase the question of who acted

The deeper problem isn't just that inheritance is unscoped — it's that a shared service account makes the question of "who acted" unanswerable after the fact. If three agents and two scripts all call out under the same account, an audit log full of that account's name tells you nothing about which of them did what. A permission grant, a denial, a scope change: each needs to be attributable to the specific agent that triggered it, not to whatever credential happened to be lying around. Standing, shared, unscoped: that's the same failure wearing three names, and it's the default outcome of not designing identity for agents at all.

What it takes to stop it

Closing this off means an agent proves who it is before anything gets brokered to it, on a per-agent identity that isn't a shared service account and isn't a copy of someone's login session. It means the authority attached to that identity is scoped to what the current task needs, not to whatever the borrowed credential happened to carry, and that authority doesn't outlive the call it was issued for. And it means every grant, denial, and scope change lands in an audit trail keyed to that specific agent, not to a name five other things also answer to. None of this is exotic access-control theory. It's the same discipline identity and access management has applied to human accounts for two decades, applied for the first time to actors that get created, reconfigured, and retired without a person ever filling out a form.

The check clears whether or not anyone meant to sign it

An unscoped inheritance doesn't wait for someone to misuse it. The moment an agent is running under borrowed trust nobody scoped, the blank check is already valid — a prompt injection, a bug, or a bad instruction doesn't need to forge authority the agent already has. The fix isn't catching the moment the check gets cashed. It's never issuing a check with the amount left blank in the first place.

Sources

• The Confused Deputy. Norm Hardy, ACM SIGOPS Operating Systems Review, 1988. The original account of a program that holds legitimate authority and is tricked into misusing it, the same shape as an agent acting under borrowed credentials.
• LLM01:2025 Prompt Injection. OWASP Gen AI Security Project. Recommends giving the application its own API tokens, handling privileged functions in code rather than handing them to the model, and restricting the model's access privileges to the minimum necessary.
• Security Best Practices. Model Context Protocol documentation, version 2026-07-28. Its token passthrough section explains how accepting upstream credentials makes it impossible to tell which client a call came from, which makes auditing and incident investigation harder.
• LLM06:2025 Excessive Agency. OWASP Gen AI Security Project. Recommends limiting the permissions an agent's extensions are granted to the minimum necessary.