Every AI Agent Is a Non-Human Identity. Stop Giving It God-Mode.

Every AI agent you ship is a non-human identity, and right now most teams are handing each one god-mode. An agent is not a feature, it is an account: it holds credentials, carries permissions, calls APIs, and acts on systems while no human watches the keystrokes. The risk that should keep you up is not that the model says something dumb. It is that the model holds a long-lived API key, a database role, and an outbound path, and a single hijacked instruction turns all of that into the attacker’s. Veza’s 2026 State of Identity & Access report put numbers on the scale: machine identities already outnumber humans 17 to 1, and just 0.01 percent of those non-human identities control 80 percent of all cloud permissions. Agents are about to make that ratio look quaint.

So treat the agent like what it is, an identity, and govern it like one. This is why the credential is your real attack surface, why your agent count is already out of control, and the build pattern that keeps a compromised agent from reaching anything that matters.

The model is not your attack surface. The credential is.

Builders fixate on the model, the prompt, the jailbreak. Attackers fixate on what the agent can touch. A chatbot generates text and that is the whole blast radius. An agent reads code, queries databases, opens tickets, sends mail, moves money. The day you give it a tool, you give it an identity with standing access, and that access does not evaporate when the conversation ends. As one widely shared take put it this month, the enterprise question has moved from “what can agents do?” to “who answers when something goes wrong?” That is an identity question, not a model question.

We have made the same argument from the prompt side in why prompt injection cannot be patched: assume the agent gets fooled, then make sure the fooling reaches nothing. Identity is the other half of that bet. A hijacked agent with a scoped, ten-minute token is an incident report. A hijacked agent with a permanent admin key is a breach.

You already have more non-human identities than people

Before you add a single agent, your stack is already drowning in machine identities: service accounts, CI tokens, webhook secrets, OAuth apps, cron jobs. The Cloud Security Alliance’s 2026 survey on non-human identity and AI security found only 15 percent of organisations feel confident they can prevent an NHI-based attack, and more than 16 percent do not track the creation of AI-related identities at all. You cannot govern what you never registered.

Agents pour fuel on this. They spawn sub-agents, request tools at runtime, and chain actions across systems that were never meant to talk. Veza found dormant accounts already make up 38 percent of all accounts and counted 824,000 orphaned identities with live entitlements and no human owner. Every agent you stand up without an owner, an expiry, and a log is one more of those, except this one can act on its own.

Configuration fatigue is why agents end up with god-mode

Here is the trap, named bluntly by Cloudflare’s Kenton Varda in a post that drew hundreds of replies: “If you have to explicitly configure each agent’s permissions, you’ve lost. Because you’re only going to have patience to configure so many agent permissions.” He is right, and it is the whole problem. Least privilege that depends on a human carefully scoping every agent dies the moment you have twenty agents and a deadline. The path of least resistance is to copy the broad role you already have, paste in the key that already works, and move on. Multiply that by a team and you have manufactured the 0.01-percent-controls-80-percent problem on purpose.

The answer is not more discipline. It is making the scoped path the easy path: identity issued automatically per agent, permissions derived from the task, credentials that expire on their own. If doing it right takes more effort than doing it wide-open, you will get wide-open every time.

Give every agent its own scoped, short-lived identity

The pattern that holds is boring and it is decided in code, not per prompt. Each agent gets its own identity, never a shared service account. That identity gets the narrowest permission set the task needs and nothing it might need later. Its credentials are short-lived and minted on demand, so a leaked token is worthless within minutes. And every action it takes is attributable, because “which agent did this, on whose behalf, with what permission” is the first question you will ask after an incident.

This is the same containment instinct we apply to the runtime in why your coding agent needs a leash and to the host in securing self-hosted AI infrastructure: the control lives outside the model, in the credential and the permission, where an injected instruction can never reach it.

Secrets leak faster now, because agents write code

The credential problem is not theoretical and it is getting worse on a measurable curve. GitGuardian’s State of Secrets Sprawl 2026 found AI-service secrets leaked to public GitHub hit 1.27 million, up 81 percent in a year, and that commits written with the help of a coding agent leaked secrets at 3.2 percent, against a 1.5 percent baseline. The tool you trust to move fast leaks keys at twice the rate. The same report counted 24,008 secrets exposed in Model Context Protocol config files alone, with 2,117 of them still valid, because the glue code wiring agents to tools is where people paste the key and forget it.

Short-lived, scoped credentials are the antidote to all of it. A token that dies in ten minutes is not worth committing, not worth stealing, and not worth much to an attacker who finds it an hour later. You cannot stop secrets from leaking. You can make the leaked ones useless.

The build checklist

Decide these once, in your platform, so the right thing is the default thing.

• One identity per agent. Never a shared service account. If you cannot say which agent did something, you cannot revoke it without breaking ten others.
• Mint credentials, do not store them. Short-lived tokens issued on demand beat a long-lived key in an env var every time, the same instinct as keeping control of your own keys and data.
• Derive permissions from the task. Scope to what this run needs, not what the agent class might ever need. Configuration fatigue is solved by automation, not willpower.
• Give every agent an owner and an expiry. An agent with no human owner is a future orphaned identity. Register it or do not ship it.
• Log every action against the agent identity. “Which agent, on whose behalf, with what permission” is the question you will need answered fast.
• Gate the irreversible. Money, deletes, deployments, and outbound messages get a human confirmation, never an implicit yes, the discipline we apply across agent orchestration at production scale.

Govern the identity, not the vibe

Agent security is being sold as a new and exotic problem, and parts of it are. But the load-bearing fix is forty years old: every actor gets its own identity, the least privilege it needs, credentials that expire, and a log of what it did. AI did not repeal that. It just created millions of new actors who never sleep and never ask permission. Decide now, while you have a handful of agents, that each one is an identity you own, scope, and can switch off. Do it later and you are auditing 824,000 orphans. We build agents this way deliberately, and the same thinking runs through building LLM features that survive production and the private deployment behind Vaultic.

Related reading: see why prompt injection cannot be patched, securing self-hosted AI infrastructure, and why your coding agent needs a leash.