Every AI agent you deploy is a new identity holding real credentials and real permissions, usually too many. Non-human identity is becoming the dominant access-control problem of the agentic era. Here is how to think about it before it becomes an incident.
Here is a question most teams cannot answer cleanly about their own deployments: when your AI agent calls an API, reads a database, or sends an email, who is it acting as, and what is the full set of things that identity is allowed to do? If the answer is fuzzy, you have already found the problem, because that fuzziness is where agentic breaches turn from a prompt-injection nuisance into a real loss.
Every agent you deploy is a new identity. It holds credentials, it carries permissions, and it acts on its own in ways a human operator does not. The discipline of managing these identities, often called non-human identity, has quietly become one of the central access-control problems of the agentic era, and it shows up directly in the OWASP Top 10 for Agentic Applications as Identity and Privilege Abuse.
Why agent identities are different
Human identity has decades of tooling and habits around it: a person logs in, their access is provisioned and reviewed, they are offboarded when they leave. Agent identities break most of those assumptions.
They are created fast and forgotten faster. An agent is spun up to do a task, granted whatever credentials made it work, and left running. There is rarely an offboarding moment.
They are over-permissioned by default, because tightening scope is friction and broad access is the path of least resistance to "it works." An agent built to read one type of record often gets credentials that can read everything, simply because that was the token on hand.
They are acted upon by untrusted input. A human with broad permissions still exercises judgment. An agent with broad permissions exercises whatever its context tells it to, including an attacker's injected instruction. Over-permissioning a human is risky; over-permissioning an agent hands its full access to anyone who can get text in front of it.
And they multiply. One human might operate many agents, and agents increasingly invoke other agents and tools, each with its own identity. The number of non-human identities in an organisation is rising far faster than the number of humans, and most access-governance programs were not built for that ratio.
The amplifier in every agentic breach
We have written about the breach chain: untrusted content hijacks the goal, then permissions decide the damage. Identity is that second step. The injection chooses what the agent attempts; the agent's identity and permissions choose how much it can reach. Almost every serious agentic incident is, underneath the prompt-injection framing, a least-privilege failure. The attacker did not escalate privileges; you had already granted them, and the injection simply spent them.
This is why identity is not a side quest to prompt-injection defense. It is the control that decides whether a successful injection is a contained event or a catastrophe.
What good looks like
- One identity per agent, scoped to its task. Resist the shared, all-powerful service account. An agent should hold the narrowest set of permissions its job requires, and no more. The goal is that a fully hijacked agent can still only reach what its task legitimately needed.
- Short-lived, auditable credentials. Long-lived static keys handed to an agent are a standing liability. Prefer credentials that expire and that tie actions back to a specific agent identity, so you can actually answer "who did this."
- Inventory and ownership. You cannot govern identities you cannot see. Maintain a real inventory of agent identities, what they can access, and who owns them, the same way you would for human accounts.
- Lifecycle, including offboarding. Agents that are no longer used should have their credentials revoked. A retired agent with live keys is an unmonitored door.
- Bind identity to action. Where agents call tools or other agents, the identity should travel with the request and be validated, not assumed, so a stolen session or forged message cannot quietly act as someone else.
Frequently asked questions
Is this a new problem or an old one in new clothes? The principle, least privilege and identity hygiene, is old. What is new is the scale and the autonomy. Agents create non-human identities faster than humans, and they spend their permissions automatically under the influence of untrusted input, which makes over-permissioning far more dangerous than it was for a static service account.
Why not just give the agent broad access and rely on injection detection? Because no single detection layer is perfect, and the cost of the miss scales with the agent's permissions. Tight identity is the control that limits the blast radius when something does get through. Detection and least privilege are complementary, not interchangeable.
How does this connect to prompt injection? Directly. Injection is the trigger; identity is the multiplier. A tightly scoped agent that gets injected does limited harm. A broadly scoped one does whatever its credentials allow. You need to defend both the trigger and the multiplier.
Where Promptention fits
Our approach to agentic defense pairs detection with restraint: catching the injected instruction at the input layer, and helping enforce policy on what an agent's identity is allowed to do and where it can send data. The strongest version of this control is organisational, scoping and inventorying agent identities the way you already govern human ones. Our role is to make sure that even a fully hijacked agent runs into a permission wall, and that the attempt is visible.
Promptention supports policy enforcement on agent actions and tool use, aligned to OWASP ASI03, Identity and Privilege Abuse.
Further reading: OWASP Top 10 for Agentic Applications (2026), "Identity & Privilege Abuse"; NIST AI Risk Management Framework.
