Agent identity is not a service account: the four properties production agents need

> ../research/agent_identity.md

§ 01 · The shortcut everyone takes

You stand up an agent. It needs to call APIs, so you mint it a service account, attach some scopes, and drop the credentials in the agent's environment. The agent works. You have, in your tracker, "implemented agent identity."

You have not. You have implemented agent authorization, which is the question of what the agent is permitted to do. Identity is a different and larger question, and the gap between the two is where the hard incidents live. When five intelligence agencies and the NSA both put agent identity and authentication at the top of their agentic guidance this spring, they were not asking whether your agent has credentials. They were asking whether, after the fact, you can answer four questions about any action the agent took.

§ 02 · The four questions

Identity, for a production agent, is the property that lets you answer these four questions about every action, during the action and long after it:

◆ Who acted? Which specific agent, which version, which deployment. Not "the billing service." The exact actor, distinguishable from every other agent and from every human.

◆ On whose behalf? The agent acted for someone: a user, a tenant, a team, the organization itself. That principal must travel with the action, because the agent's permission to act is borrowed from them.

◆ Under what authority? What granted this action: a standing policy, a one-time human approval, a delegated scope with an expiry. Authority is not the same as capability. The agent may be capable of an action it has no current authority to take.

◆ Can it be revoked, now? When something goes wrong, can you cut this agent's ability to act without taking down every other agent that shares the same credentials? If revoking one agent means rotating a secret that forty agents share, you cannot actually revoke.

A service account, on its own, answers none of these cleanly. It is one shared identity, often long-lived, frequently reused, with capability baked in and behalf-of and authority left implicit. It is the agent equivalent of every employee sharing one login.

── Property one: distinct and attributable ──

§ 03 · Property one: distinct and attributable

Every agent instance must be distinguishable in your logs from every other agent and from every human. This sounds obvious and is routinely violated, because the easy path is to share one set of credentials across all instances of an agent, and often across several different agents.

The test is simple. Pick any action in your audit log from last week. Can you name the exact agent, and its version, that took it? If the answer is "one of our agents, we are not sure which," you do not have attributable identity. You have a shared key. The day you need to answer "which agent did this and what else did it do" is the day you discover the difference, and it is always a bad day.

Attribution also has to survive composition. When agent A calls agent B which calls a tool, the action at the tool must still trace back through B to A to the original principal. A flat identity that collapses at the first hop is not attributable in any multi-agent system, which is most production systems now.

── Property two: behalf-of, carried not assumed ──

§ 04 · Property two: behalf-of, carried not assumed

An agent rarely acts for itself. It acts for a user, a customer, a tenant. Its right to read a record or send a message is borrowed from that principal. The principal must be carried explicitly through every call, not inferred from which agent is running.

The failure here is the confused deputy. The agent has broad capability because it serves many principals. A request arrives, the agent acts with its full capability, but it acts for principal X using access that only principal Y should have reached. No credential was stolen. The agent simply failed to scope its borrowed authority to the principal it was serving in that moment. This is one of the most common ways agent systems leak data across tenants, and it is invisible to a permission model that only knows the agent, not the principal behind the request.

Carry the principal. Scope every read and every write to the principal on whose behalf the agent is acting right now, not to the union of everyone the agent could ever serve.

── Property three: authority is scoped and time-bound ──

§ 05 · Property three: authority is scoped and time-bound

Capability is what the agent could do. Authority is what it is allowed to do right now, and authority should be the smaller set, granted narrowly and expiring.

The minimal footprint principle, which appears in both the Five Eyes and NSA guidance, is least privilege restated for agents: an agent should hold only the permissions and data access the current task requires, and hold them only for as long as the task runs. A standing grant of broad capability "to be safe" is the opposite. It is a permanent authority the agent carries between tasks, available to anything that hijacks the agent in between.

In practice: prefer short-lived, task-scoped credentials over long-lived broad ones. When a human approves an action through the approval queue, that approval is a unit of authority with a subject and an expiry, and it should be recorded as such. Authority that never expires is not authority. It is a standing risk.

── Property four: revocable in isolation ──

§ 06 · Property four: revocable in isolation

The last property is the one teams discover only during an incident. When an agent misbehaves, you need to stop it, and stopping it must not require stopping everything else.

If every agent shares one service account, revocation is all or nothing. To cut the misbehaving agent you rotate the shared secret, which severs every other agent using it. So nobody revokes during the incident, because the cure is an outage. The agent keeps acting while you debate.

Isolation means each agent, ideally each deployment, holds credentials that can be revoked on their own. The kill switch from the production patterns and the revocation story from identity are the same requirement seen from two sides: the ability to make one agent stop, fast, without collateral. Build it before you need it, because you will need it without warning.

── Putting it in a file ──

§ 07 · The IDENTITY.md

Create an IDENTITY.md per agent. It records the agent's distinct identifier and how attribution is preserved across calls, how the principal is carried and scoped on every request, how authority is granted (standing policy, approval, delegated scope) and how it expires, and the revocation procedure for this agent in isolation. It names the owner and the last review date.

This document is what an auditor asks for and what your on-call engineer reads at three in the morning when an agent is doing something it should not. A service account in an environment variable answers none of its questions.

── End of note ──

ORBIRESEARCH