Identity for Non-Human Actors

The incident review is on a Tuesday, because incident reviews are always on a Tuesday. Something touched two production tables it had no business touching, and now there's a conference room, a projector, and a security lead scrolling through the audit trail. The trail is complete. Every action is there, timestamped and ordered. And every single action was performed by the same actor: svc-prod-api.

svc-prod-api was created in 2021 by an engineer who left in 2023. Its password lives in the wiki, on a page titled "Service Accounts (DO NOT SHARE)," which has been viewed a few hundred times by people who all needed it for something. Eleven systems authenticate with it. Four teams use it. Two vendors have it in a config file somewhere. And last quarter, somebody handed it to the new AI agent pilot, because the agent needed database access and the account was right there, warm and willing, the way it always is.

The security lead asks the only question an incident review exists to answer. Who did that?

The room already knows. The service account did it. Which means nobody did it. Which means anybody did it.

An audit trail where every actor is svc-prod-api is not an audit trail. It's a suspect pool.

That's the paper. When agents start doing real work, "who did that" becomes the most important question in your system, and the shared-service-account model guarantees you can never answer it. The rest of this is what agent identity actually requires, the anti-patterns that look like identity but aren't, and the questions to ask of any platform that wants you to trust its answer.

The service account was built for a quieter world

The shared service account is a fossil from an earlier era of automation, and in that era it was fine. The machine actors were cron jobs. One script, one schedule, one narrow job. The script ran at 2 AM, moved some files, and went back to sleep. Nobody needed to know "which" cron job did it, because the answer was obvious and the blast radius was a directory.

Identity that means "some machine, probably" held up because the actions were dumb and the volume was low.

Then the actors changed. An autonomous agent is not a cron job. It reads context, makes judgments, chains actions across systems, and does it at a rate no human session was ever designed to represent. An agent can make hundreds of calls in the time it takes you to sip your coffee. It can open a pull request, query a customer table, draft an email, and spend money, all before the session cookie that "authenticated" it has finished being misappropriated.

That's the collapse. Session cookies were designed for a human at a keyboard: one person, one browser, a pace measured in clicks. Service accounts were designed for scripts: one job, one schedule, a pace measured in nights. An agent org is neither. It's a workforce. And a workforce where everyone shares one badge is not a workforce you can govern. It's a crowd with an alibi.

The scale of this is already past the point where it's a rounding error. CyberArk's 2025 Identity Security Landscape, a survey of 2,600 security decision-makers conducted by Vanson Bourne, found 82 machine identities for every human identity in the organization, with 42% of those machine identities holding privileged or sensitive access (CyberArk, 2025). That ratio was already steep before agents. Agents are the accelerant, because every agent that spins up is another identity, and if your answer to "who is this" is a shared account, you just added one more shovel to a hole you were already standing in.

Identity, per agent, per call

The first requirement is the one most platforms skip because it's inconvenient: a unique identity per agent, not per fleet. Not one account named ai-agents that forty agents share. One identity for the agent that reviews code. A different identity for the agent that answers support tickets. A different one again for the agent that reconciles invoices. If two agents can produce the same row in your audit trail, you don't have two identities. You have one identity with two jobs, which is the svc-prod-api story with better branding.

The second requirement follows from the first: per-call credentials scoped to what that agent may do on that task. Not a long-lived key that grants everything the agent might ever need. A credential minted for this task, carrying this agent's authority, expiring when the task does. The agent reviewing a pull request gets read access to that repository, for that review, and nothing else. When the task ends, the credential is a museum piece.

This is the same shape as the authority registry pattern that runs through this whole series. In the agent org that runs SpeyAI, what an agent may touch is a column the pipeline reads at runtime, and the credential the agent carries is the enforcement of that column. The Org Chart Is Code covers the registry side. Identity is the registry's handshake with the outside world.

A credential that outlives the task is a key someone forgot in a door.

Revocation, and the propped-open fire exit

Walk into any secure facility and watch the badge system work. Every door, every badge, every timestamp. The badge reader doesn't care that you're well known or that you're in a hurry. It reads the badge, checks the authorization, logs the event, and opens or doesn't. When someone leaves the company, security disables one badge and that person's access to every door dies in the same second.

Now walk around the back of the same facility and find the fire exit propped open with a brick, because the smokers got tired of badging back in.

The shared service account is the brick. It doesn't matter how good the badge system is if there's one door that everyone uses and nobody logs. And revocation, the thing the badge system does in one second, becomes a quarter-long migration project: rotate the credential and eleven systems break, four teams file tickets, and two vendors need a change window. So nobody rotates it. The account that most needs killing is the one account you can't kill.

Per-agent identity makes revocation surgical. One agent misbehaves, one identity dies, instantly, and the other agents keep working. That property matters more with machine actors than with humans, because a compromised human does damage at human speed and a compromised agent does damage at machine speed. The time between "we should cut this off" and "it is cut off" is measured in actions taken. At hundreds of calls per second, a slow revocation isn't a delay. It's a body count.

Auditors are already naming this gap. Writing in ISACA's industry journal, Nirupam Samanta describes agent deployments where the identity inventory explodes overnight with ephemeral identities that never had a formal review and disappear before governance tools can act, leaving "no record of provisioning, ownership, access rationale, or deprovisioning for most of these identities" (Samanta, 2025). That is the lifecycle half of the same problem. Attribution asks who did it; lifecycle asks who created this actor, who owns it, and who is supposed to end it. An identity nobody remembers minting is an identity nobody will remember to kill.

The name on the ticket

Third requirement: attribution stamped into every artifact the agent produces.

There's a difference between "the kitchen made your food" and the line cook's name on the ticket. Both describe the same meal. Only one of them is useful when the meal goes wrong. The name on the ticket means someone specific seasoned that dish, someone specific can be asked what happened, and the pattern of tickets over time tells you which cook is having a bad month.

In an agent org, every artifact carries the ticket. The brief that recommended the decision names the agent that wrote it. The code change names the agent that authored it and the different agent that reviewed it (the separation matters, and No One Audits Themselves is the paper on why). The row in the audit lifecycle names the identity that performed the action, under what authority, on which task.

This is where identity connects to the two papers it leans on. Files, Not Memories established that agents hand off through artifacts on disk, discrete and inspectable. Logs Are Not Audit established that a queryable audit lifecycle is the difference between having data and having answers. Identity is the ingredient both of them silently assume, because a row is only as good as the identity in it. A perfect audit lifecycle populated by svc-prod-api is a beautifully indexed shrug.

Humans are not agents, and agents are not humans

Fourth requirement, and the one with teeth: hard separation between human identity and agent identity. An agent must never borrow a person's login. A person must never act under an agent's identity.

Both directions fail in the wild, and both fail the same way: they poison the trail. When an agent runs under Dave's credentials because "it was faster to set up," every action the agent takes is attributed to Dave. Dave's access review now includes ten thousand actions Dave never took. When Dave's judgment gets questioned in the incident review, Dave gets to explain that it wasn't him, it was the agent, and now you're relying on Dave's memory to partition an audit trail. Dave's memory is not an identity system.

The reverse is worse. A person acting under an agent's identity has found the one costume in the building that nobody questions. The agent's actions are assumed to be mechanical, high-volume, and boring. A human hiding in that stream is a human who has learned that the best place to stand is behind the actor everyone has stopped watching.

Banks solved this a long time ago with signing officers. A corporate account doesn't accept a check signed by "the finance department." It accepts checks signed by named officers, registered in advance, with limits per officer. The signature binds a specific person to a specific instrument. Nobody at the bank considers this bureaucratic. They consider it the reason the account is trustworthy.

The anti-pattern gallery

Three exhibits, all common, all fatal to the trail.

One API key for the whole fleet. The vendor's onboarding doc says "create an API key," singular, and the whole fleet inherits it. Every agent is now the same actor. When the key leaks (it will; it's in forty config files), the revocation takes the entire fleet down at once, so the key stays live while everyone debates. This is svc-prod-api reborn in the cloud, with the same wiki page waiting to be written.

Agents impersonating the user who triggered them. The agent acts "as" whoever clicked the button, riding the user's session. It feels elegant. It means the agent's authority silently inherits every permission the human has ever accumulated, including the ones from that project in 2022 nobody remembers granting. The agent should act under its own identity, with the triggering user recorded as exactly that: the trigger, not the actor.

Credentials that outlive the task. The agent finished the migration in March. The credential still works in November. Every long-lived credential is a bet that nothing between March and November went wrong, and the house always collects on that bet eventually.

The trail must survive an argument

Here's the bar, and it's higher than "we have logs."

Non-repudiation means the trail holds up when someone is motivated to dispute it. Not the friendly Tuesday review where everyone wants the truth. The unfriendly version: a regulator with a document request, a customer with a lawyer, a vendor pointing at your agents while you point at theirs. In that room, "the service account did it" is not an answer. It's an admission that your system was built to make sure the question could never be answered.

A trail survives an argument when every row binds an action to a unique identity, the identity binds to a scoped credential, the credential binds to a task and an authority that a registry granted, and none of those bindings can be quietly rewritten after the fact. Each link is boring. The chain is the whole case.

That's what identity is for. Not compliance theater. The ability to make a claim about what happened and have the claim hold under pressure from someone paid to break it.

What to ask before you trust the answer

The value of a principle is that it converts into questions you can ask a vendor with the check still in your pocket. Here are the identity ones.

Does each agent have its own identity, or does the fleet share one? Show me two agents in the audit trail and prove they're distinguishable.

Are credentials scoped per call and per task, or long-lived? What's the longest-lived credential in the system right now?

Walk me through revoking one agent, right now, without touching the others. How long does it take? Who can do it?

When an agent produces an artifact, where is the attribution stamped, and can it be altered afterward?

Can an agent ever act under a human's login? Can a human ever act under an agent's? What structurally prevents it, as opposed to what policy discourages it?

A platform with a real identity story answers these in minutes, with queries. A platform without one answers with a roadmap slide. The difference is whether your next incident review ends with a name on the ticket or a room full of people staring at svc-prod-api, the employee of the month, every month, since 2021.

The takeaway: Agents doing real work need real identity: one identity per agent, credentials scoped per call and per task, revocation that works in seconds, attribution stamped into every artifact, and a hard wall between human and agent identity. The trail this produces is the point, because the trail must survive an argument, not just a dashboard. A shared service account guarantees the opposite: an audit trail that is complete, orderly, and incapable of answering the only question that matters.

References

1. SpeyAI agent org architecture. Live reference at speyai.com.

2. National Institute of Standards and Technology. (2017). NIST Special Publication 800-63-3, Digital Identity Guidelines. The framework treatment of identity proofing, authenticators, and federation, including the binding of authenticators to a single subject, the property shared service accounts structurally violate.

3. National Institute of Standards and Technology. (2020). NIST Special Publication 800-207, Zero Trust Architecture. Per-request access evaluation as an architectural principle: access granted per session and per resource rather than through standing broad credentials, the standards-body version of per-call, task-scoped agent credentials.

4. CyberArk. (2025). 2025 Identity Security Landscape. Survey of 2,600 security decision-makers, fielded by Vanson Bourne (released April 23, 2025). Reports 82 machine identities for every human identity, with 42% of machine identities holding privileged or sensitive access.

5. Samanta, N. (2025, September 2). The Growing Challenge of Auditing Agentic AI. ISACA Industry News. On the audit consequences of agent deployments, including separation-of-duties violations when an agent grants access without formal approval, and the identity-lifecycle gap where ephemeral agent identities carry no record of provisioning, ownership, access rationale, or deprovisioning.

This paper is part of Rise of the Agent Org, a series by Ed Hoehn, SpeyAI. The full library is at speyai.com/record.