Your AI agent has a service account problem

Every agent proof-of-concept I have watched ends the same way. The demo works, everyone is pleased, and somewhere in the last ten minutes an engineer pastes an API key into a config file. Nobody mentions it. The key is good for a year, it has admin scope because narrowing it would have meant another ticket, and it now lives in an environment variable on a box that three teams can reach.

We just created an identity. We gave it standing privilege, no expiry, no owner, no review cycle, and no way to tell what it did. If a human asked for that, the request would not survive the first conversation.

Agents break the model because they are neither thing

Identity programmes are built around two categories. People, who join, move and leave, get access reviewed, and sign in with factors. Machines, which are predictable: a nightly job that reads one database, a load balancer health check, the same call at the same time with the same scope forever.

An agent is neither. It behaves like a person — it reasons, it chooses, its next action is not knowable in advance — while authenticating like a machine, with a static secret and no session, no device, no step-up. You get the unpredictability of a human with the accountability of a cron job.

That combination is new, and it is why the usual controls land badly. Access review asks "does this person still need this?" — a question with no meaning for something that has no manager and no leaving date. Anomaly detection asks "is this behaviour unusual for this account?" — but the agent's whole job is to do something different each time. The signals we rely on are calibrated for entities that are either consistent or human. Agents are neither.

The honest version of what you granted

Ask the question concretely, about one agent you have running today:

• Which systems can it reach, not in theory but with the credential it holds right now?
• If its prompt were manipulated into attempting the worst action within that scope, what is the worst action?
• Who approved it, and can you produce their name without asking around?
• When does the credential expire? If the answer is a year, it is a password with better branding.
• If it were compromised this afternoon, how would you know — and what would you look at?

Most teams can answer the first one, roughly. The second is usually met with a pause, because blast radius is not a property of one system — it is the union of what the SSO claims permit, what the entitlements grant, and what the vaulted service account can do. Nobody holds all three in one place.

The uncomfortable version: a support-triage agent with okta:app-admin can, in the worst case, do everything an Okta administrator can do. Not because anyone intended it, but because that was the scope on the shelf when someone needed it to work before a demo.

Prompt injection is a privilege problem wearing a costume

There is a lot of writing about prompt injection as though it were a model problem, solvable with better guardrails. It is worth being precise: injection is how an attacker talks to your agent. Privilege is what happens next.

An agent that reads a malicious support ticket and has read-only access produces a wrong answer. The same agent with a long-lived admin token produces an incident. Identical injection, identical model, wildly different outcome — and the variable is not the prompt, it is the credential.

This is good news, because privilege is a problem our industry already knows how to solve. We have spent twenty years learning that standing admin is a bad idea for humans. Everything we learned applies, provided we are willing to admit the agent is an identity and not an integration.

What "zero standing admin" actually requires

It is an easy phrase to put on a slide and a genuinely hard thing to build. Three parts, in increasing order of difficulty:

One skill, one credential. Decompose the agent. The thing that reads vendor metadata does not need write access to anything. The thing that creates the app needs app-admin and nothing else. The thing that scores risk needs no credential at all. Most agents are over-privileged because they are one monolith that occasionally needs to do one dangerous thing.

Credentials with a time limit measured in seconds. Not rotation — expiry. Rotation means the window is ninety days instead of forever. A token minted for a specific task and dead ninety seconds later is a different category of thing. This is the part most teams skip, because it requires a broker that can mint scoped tokens on demand, and that is real infrastructure.

An orchestrator that holds nothing. The component doing the planning should have no platform credentials whatsoever. It proposes; something else decides; a third thing executes with a borrowed, scoped, expiring credential. If your planner can write to production, you have built a very articulate admin account.

The part people skip

A named human in the loop, before the write.

This gets argued about, usually on the grounds that approvals defeat the purpose of automation. They do not, if the approval is a diff rather than a document. Reading a proposed configuration — these claims, these entitlements, this service account, this scope — takes about ninety seconds and it is the only moment where the cost of saying "no, not that scope" is zero.

What defeats the purpose of automation is a ticket that sits in a queue for four days so somebody can read a Word document describing what will probably be built. That is not an approval. That is a delay with a signature attached.

Where we landed

IdenAxis is built on the assumption that the agent is the identity. Seven specialised sub-agents, each holding one skill and a credential that lives only as long as its task — okta:app-admin for ninety seconds, vault:onboard for sixty, nothing at all for the ones that only read and reason. The orchestrator plans and delegates and holds no platform credentials of its own, and stops the moment policy says no.

And the identity that comes out the other end gets scored before anyone celebrates — seven layers, at creation time, while changing it is still free.

None of that is exotic. It is least privilege and separation of duties, applied to something that reasons. The only genuinely new part is admitting that the thing you just deployed is an identity, and that it deserves the same scrutiny as the contractor you onboarded last week with considerably more paperwork.