Non-Human Identity Security for AI Agents: Design for a Credential That Gets Misused

A sentence turns up in nearly every agent design review, almost always from whoever sits closest to shipping. The platform already holds credentials, so point the model at those credentials and get on with the demo. Nobody says it with malice. It is the shortest route from prototype to something a stakeholder can watch on a screen.

It is also the decision that turns a hostile paragraph in a stray document into a reportable event. An agent does not resemble an employee, and it does not resemble the batch job your platform team has run for six years. It picks its next move at runtime, from prose, and a portion of that prose arrives from outside your perimeter. What follows is why ordinary machine-identity practice fails to transfer, and then the half worth reading twice: what to build in its place.

The Assumption Hiding Behind a Spare Set of Keys

Stated plainly, the assumption holds that an agent is one more workload, and workloads get workload credentials. That reasoning deserves some respect. A decade of cloud security work went into retiring shared human logins and handing every deployable unit an identity of its own. Treating a new component the same way is the grown-up instinct, not a lazy one.

What changes is the job the credential now does. Fixed code makes a fixed set of calls, so a reviewer reads the code and judges whether the grants match. An agent runs a loop, and inside that loop a model decides what comes next. The permission set stops describing behaviour and starts bounding it: the grant is now the furthest any ticket, web page, document or inbound message can push the system. In most first deployments that bound is a broad key, because a broad key is what made the prototype work on a Friday afternoon.

Volume turns the habit into a structural problem. The 2025 Identity Security Landscape from CyberArk, drawing on 2,600 respondents in security decision-making roles, counted machine identities outnumbering people by 82 to one in the organisations it surveyed, put 42% of those identities on privileged or sensitive access, and found 88% of respondents reserving the term "privileged" for human beings alone. Read the exact figures as what they are, a vendor's survey of its own market. The shape still matters more than the decimals: the identities nobody reviews are holding the authority.

Agents then multiply the count. A team stands one up for a pilot, issues it a key, and moves to the next quarter's roadmap. The pilot stops. The key does not, and OWASP has a name for what happens next, defining improper offboarding as the failure to deactivate or remove a non-human identity once it has stopped serving any purpose. It sits at the top of that project's list for a reason.

Four Ways the Assumption Fails Once Agents Are Live

These patterns recur across deployments, described here at the altitude a defender needs rather than as anything reproducible.

• One key, many actors. A single API credential serves two agents, a cron job and a staff engineer who was debugging something in March. Downstream logs record the credential. They cannot record which agent, which task or which prompt caused the call, so the first question of any investigation has no answer.
• Secrets in reachable places. OWASP tracks credential leakage into unsanctioned stores as the second entry on the same list. Agents widen the set of such stores considerably: tool results, persistent memory, trace exports, evaluation fixtures and the context window itself. Anything the model is able to read is something a planted instruction can ask it to repeat.
• Identities with no owner. An abandoned experiment leaves a valid credential behind. No name is attached, so no rotation happens, and no renewal review ever fires.
• Grants that only ever grow. A permission gets widened to unblock a failing task and is never narrowed afterwards. Six months later the agent's grant describes a system nobody designed.

For the mechanics of a hijacked call spending those grants, our analysis of how attackers hijack tool calls in agent pipelines covers the sequence. The authority side is in privilege escalation in agentic systems.

A Mental Model That Survives Contact With Production

Treat every credential within an agent's reach as narrow, expiring authority which will be spent wrongly at least once. Three commitments replace the old assumption.

1. Attribution runs per agent, per task. Who did this has to resolve to exactly one answer, and a single log line has to supply it without anyone correlating three systems by timestamp.
2. Issue at the moment of use. A token alive for the length of one task is worth far less to whoever steals it than a key alive for the length of a fiscal year.
3. No secret ever enters the model. Custody belongs to the tool layer. The model requests an outcome, and code outside it rules on whether that outcome is permitted.

This is the same ground covered in why least privilege gets harder with agents, pushed down one level to the credential itself rather than the permission model around it.

Controls Worth Putting In, and the Order to Put Them In

• Produce the list before you buy anything. Every agent, the credential it presents, a named owner, and the date it last authenticated. An entry with no owner is itself a finding, and you can assemble the whole thing from existing cloud and vault exports.
• Stop sharing credentials. One identity per agent, never shared with a second agent and never shared with a person. Name identities so that a raw log line points at the agent without a lookup table.
• Move to brokered, task-scoped tokens. Your cloud's workload identity service or a token broker will issue these. Scope each one to the tools and the data the current task needs, not to the agent's full job description.
• Keep credentials out of the context window. A tool wrapper attaches the secret at call time and returns only the result. Run secret scanning across prompts, traces and memory stores, since all three are places where a credential ends up by accident.
• Record identity on every tool call. Agent, task, tool, a classification of arguments, and the size of the result. Without those fields incident response for agentic systems turns into guesswork under time pressure.
• Make expiry the default and renewal the exception. Give every agent identity an end date. Renew it only when a named owner asks, which also keeps the inventory honest at no extra cost.

None of this eliminates anything. A narrow token can still be spent badly inside its own narrow scope, and a short lifetime does nothing about what happens during that lifetime. The goal is a smaller radius and a readable trail, which is a different and more achievable claim.

The Platform Vendors Caught Up, Partly

For most of the last two years the three commitments above were something you assembled yourself out of a vault, a token broker and a naming convention nobody enforced. That is no longer true. Microsoft's Entra Agent ID documentation now describes an agent identity as a service principal that, in its own words, "doesn't have credentials on its own". It authenticates only through federated identity credentials issued by a separate object called an agent identity blueprint, and the blueprint is where the certificate or the client secret actually sits. The agent gets a subject inside the access token. It never gets a key.

Two details on that page are worth copying even if you never run Entra. The first is the sponsor: a field on the agent identity recording which human or group is accountable for it, there so that somebody can be reached when an incident involves that agent. That is the owner column from the inventory step, promoted out of a spreadsheet and into the identity object itself. The second is that the blueprint holds the class-level permission grants, which lets an administrator revoke a grant or disable every agent of one kind in a single operation. Ask whoever runs your identity provider whether they can do that today. It is the difference between one contained incident and nineteen separate tickets.

The gap is narrowing, not closed. Proofpoint's reference page on non-human identity, drawing on its 2026 AI and Human Risk Landscape report, puts 76% of organisations piloting or rolling out autonomous agents while 52% say they are not fully confident their controls would spot a compromised AI agent. A vendor surveying its own market is directional evidence, not a measurement. The direction is that deployment is outrunning detection, which is the same ordering failure the inventory step exists to catch.

One Credential Per Agent Is the Wrong Purity Rule

This is where we part company with most non-human identity guidance. Nearly all of it converges on the same pair of moves: get static secrets out of code and into a manager, then rotate whatever is left on a schedule. OWASP's secret leakage entry lists that alongside replacing static secrets with short-lived, on-demand ones, and the advice is correct. The usual implementation of it, one durable secret per workload, is what breaks at agent scale. Forty agents across six kinds becomes forty secrets to rotate, forty places a secret can leak from, and forty rotation jobs that fail quietly on a Sunday. The blueprint pattern splits the problem instead: credential custody gets centralised, attribution stays distributed. One credential, many identities, every token naming the individual agent as its subject. Keep the identity per agent. Drop the insistence on a key per agent.

The cost nobody puts in the slide deck is what this makes of the blueprint. A credential able to mint tokens for every agent of a kind is a tier-zero secret and needs tier-zero handling: hardware-backed where the platform allows it, no human read path, an alert on any use that does not line up with a known agent start. Centralising custody does not reduce the number of things that can go badly wrong. It reduces them to one and raises the stakes on that one considerably.

Blast radius decides this. If one blueprint's compromise would hand an attacker every agent of that kind at once, and your tolerance cannot absorb that, split blueprints by trust tier rather than by product kind: read-only agents in one, agents that can write or move money in another. And if you cannot say today which of your agents can write, then that is the question to work on first, and it is not this one.

Where to Start This Week

1. Export every service account and API credential that an agent can present. Flag the ones used by more than one thing.
2. Take the five most privileged entries. Cut each grant down to what last month's access logs show it actually used.
3. Pick one agent and move it onto brokered short-lived credentials, as a pattern the next ten can copy.
4. Attach an owner and an end date to every remaining agent identity.
5. Run a secret scan over that agent's prompts, traces and memory, and treat any hit as a live rotation.

Treat all of the above as technical analysis rather than an audit. Production risk decisions deserve a qualified security review against your own architecture.

A note on sequencing, because the order above is not arbitrary. The inventory comes first not because it is the strongest control but because every other item on the list needs it as input. You cannot scope a grant you cannot find, you cannot expire an identity with no owner to ask, and you cannot attribute a call to an agent that appears nowhere in a register. Teams that start with the token broker, which is the interesting engineering, routinely discover six months later that the broker covers the eleven agents they knew about and none of the nineteen they did not.

Questions about agent credentials and non-human identity

What counts as a non-human identity?

Any credential standing in for software rather than a person: service accounts, API keys, bearer tokens, client certificates, workload identities. An agent of any ambition will touch several of them in a single task.

Should the agent act as the user or as itself?

Both, carried in one token. Delegation keeps the agent's own identity intact while recording the principal it acts for, which is what makes an audit trail readable months later.

Do short lifetimes make scope less important?

No. A short lifetime limits the window in which a stolen token works. It places no limit at all on what that token can do while it is valid, so scope stays the control that bounds damage.

How often should an agent credential rotate?

Prefer issuing a fresh credential for each task over rotating a durable one on a calendar. A calendar interval is a compromise you accept when your broker cannot issue per task.