AI agent identity: the design model nobody has standardized

The first few months of building with AI agents, most teams do the same thing. The agent logs in as the human. Writes as the human. Edits as the human. Every action in the audit log carries the human's name, every comment shows the human's avatar, and the team gradually learns to tell which "Govind edits" actually came from Govind versus the model running with his credentials.

This works for about three days. Then it breaks in three predictable places, and the fix is the same one every team eventually arrives at: agents need their own identities.

This essay is the pillar argument for that claim. What the three cracks are, what an agent identity needs at minimum, why service accounts are the wrong shape, what the correct shape looks like in practice, and the design pattern (signed-agent inheritance) that makes mixed human-and-agent teams actually auditable.

The three cracks in "agent runs as the user"

Run the agent as the user for long enough and three failure modes show up.

Trust. A teammate sees a big change in a shared doc at 2am and assumes the human was up. Or worse, was up and sloppy, because the agent produced something that reads differently from how the human writes. The human's credibility sits on the agent's output whether they reviewed it or not. Multiply by ten agents and the human is responsible for opinions they've never read.

Debugging. Something went wrong in an automated loop. The audit log says the human did it. The human didn't. The agent that did doesn't have a row anywhere queryable. An hour disappears recovering context that should have been one row of state.

Scale. Running two agents as the same user means the audit log conflates both. Running six means the human can't tell them apart even to themselves. If the human rotates their password because a security scanner flagged something, every agent in the org logs out at once. The infrastructure is wired such that the human is the failure unit for every agent's session.

Each crack alone is annoying. Together they argue that the architecture is wrong. The fix isn't more tooling on top of the human-as-agent model. It's giving the agent its own identity.

What an agent identity actually needs

The minimum viable agent identity is five things. Skip any one and the design degrades back into one of the three cracks above.

• Its own principal id, distinct from any human. Every event the agent emits, every row it writes, every comment it posts attributes to the agent, not to whoever owns the agent. The audit log can be reconstructed from the agent's identity alone, not by inference from the human's.
• Its own credential, separate from any human password, session cookie, or OAuth token. Rotating the agent's key doesn't log out the human. Revoking the agent doesn't lock the human out of their own account.
• Attribution to an owning human. You need the accountability link: whose agent is this, who's responsible when it misbehaves. This is also the substrate for the trust model, which we'll come back to.
• A name and a face. Agents show up in lists next to humans. If the UI makes them indistinguishable, the human half of the conversation can't hold context. If the UI makes them alien (robot icons, monospace labels), the team disowns them. The right shape is the same shape humans get: an orb or avatar, a display name, a profile.
• A scope, not an inheritance. What the agent can read, write, and call is explicit, not implicit from its owner. Default-deny on everything outside the explicit scope. A misbehaving agent should be containable; it should not be able to act everywhere its owner can.

Most products that "support agents" today get three of these and miss two. The two they miss are usually principal id (the agent's actions are attributed to the human anyway) and scope (the agent inherits all of the owner's permissions). The combination is what makes agent operations untraceable and uncontainable.

Agents are principals, not delegates

The framing that breaks the most teams is this: there are two ways to think about an AI agent in software, and they look similar but produce wildly different architectures.

One: the agent is a delegate. The agent runs with the human's API key. When the agent does something, the human did it. When it goes wrong, the human fixes it. There's no separate accountability surface because there's no separate principal. Most products today are quietly built on this model. The agent is a delegate, its key is the human's key, its actions are the human's actions, and the accountability story is "trust us, we'll log it."

Two: the agent is a principal. It has its own identity, its own credential, its own audit trail. The human owns it the way they own a service account or a teammate's invite. The human can grant it access, revoke it, delegate to it, see exactly what it did. But the agent is not the human. It's a thing that acts on its own behalf, and the system knows the difference.

Once an agent is a principal, six other things follow. Every agent has an owner. Audit logs are dual-keyed (actor + owner). Access can be scoped to one workspace without scoping the owner. The agent can be paused, rotated, or revoked without touching the human. The agent can collaborate with other agents under its own name. The team's org chart can grow agents as nodes, not as user-attached artifacts.

These six are downstream of the framing choice. Pick principal early and the rest is mechanical. Pick delegate early and every one of the six requires a special case that doesn't quite work.

The anti-pattern: agents borrowing human credentials

The most common implementation today is the one that looks easiest: the agent uses the human's API key, session cookie, or OAuth token. "It's just my own key, what's the worst that could happen."

The worst is that the agent's actions are indistinguishable from the human's, both to humans and to systems. The audit log says the human did it. Compliance review says the human did it. Forensics on a security incident say the human did it. The human carries the blast radius for everything the agent does, which means the human can't responsibly delegate to the agent for anything serious.

Worse, the credential laundering goes both ways. Tools that accept the human's token from the agent treat the agent's calls as human calls. Rate limits intended for one human are bypassed. Two-factor protections intended to gate the human are bypassed. Audit reviews that intended to look at human activity miss the agent activity entirely. Every "trust this human" decision the rest of the system makes is silently extended to every agent the human runs, with no way for the system to know.

The fix is per-agent credentials issued at agent creation. Not the human's key. Not a service account the human shares with five agents. The agent's own key, tied to the agent's own identity, attributed to the agent in every downstream system the agent touches.

Signed-agent inheritance: how access propagates

If agents are principals, how do they get permission to do anything? The naive answer (grant per-workspace, per-agent) doesn't scale: a team running ten agents across twenty workspaces is managing 200 permission rows.

The shape that ends up working is signed-agent inheritance: every agent has a required owning human, and the agent inherits access to whatever its owner has access to, automatically.

That's the access model. The accountability is the same flow: the owning human is responsible for the agent's actions. Access is a property the human extends to the agent (you can do what I can do, in workspaces I can do it in). Accountability is a property the human absorbs from the agent (I am responsible for what my agent does).

This pattern has several consequences worth naming:

• You manage Dock by managing your humans. Add a human to a workspace, their agents inherit. Remove a human from a workspace, their agents lose access in the same transaction. Permissions stay simple because they're keyed to people, not to (people × agents).
• Cross-org access is the design, not the exception. If a human is invited to a workspace in another org, their agents (in their original org) inherit access. The trust substrate is the owner, not the org boundary. Org membership of the agent is a routing concern; org membership of the owner is the trust concern.
• Org-visibility ("any agent in the org") stays a separate concept. Inheritance is per-owner. The "any agent in the org can see this org-visibility workspace" model is a different shape, used for organization-wide artifacts; it doesn't conflict with inheritance.
• The cascade is atomic. Remove a human's access to a workspace, their agents lose it in the same transaction. No window where the human is gone but agents linger.

The pattern is the bridge between "agents have identities" (necessary for accountability) and "I don't want to manage permissions for every agent" (necessary for usability). Both work because the owner is the gravity well.

Service accounts vs agent identities

The instinct from the systems-engineering tradition is to model agents as service accounts. It's wrong, and the difference matters.

A service account is an identity not tied to any human. It exists independently. Its credentials are administered by whoever has admin access; rotation is a manual process; access is granted per-resource. Service accounts were designed for cron jobs and integration glue: long-lived, infrequently-touched, run-by-the-org-not-a-person.

An agent identity is tied to a human owner. It exists because someone runs it. Its credentials are administered by the owner; rotation can be self-service; access derives from the owner's. Agent identities are designed for interactive, frequently-touched, run-by-the-person-on-their-behalf.

The tells that you've modeled an agent as a service account when you shouldn't have:

• The agent's audit trail terminates at "the org," not at a specific human you can ask.
• Removing a teammate doesn't remove their agents (because the agents exist independently).
• Granting access requires per-agent admin steps, not just inviting the human.
• Rotating the agent's key requires admin tooling, not the owner's self-service flow.

If any of these are true, the model is service account, not agent identity. Migrating from one to the other is mostly a data migration: add ownerUserId (required), cascade access changes through it, retire the per-agent admin tooling.

For genuinely org-owned automations (a nightly job that nobody specifically owns), service accounts are still right. For agents that humans interact with and are responsible for, agent identities are the shape.

How to design an agent identity model

If you are designing the identity layer for an agent platform (or auditing an existing one), the six decisions below define the shape. Walk through them in order. Each one is a fork that affects the others.

1. Pick principal, not delegate. Decide at the schema level that the agent is its own thing with its own row. The temptation to skip this and "just use API keys" returns the three cracks above within weeks. The right choice is a new entity (call it Agent, AgentIdentity, whatever), with its own id, credential, and lifecycle.

2. Require an owning human at agent creation. Every agent has an owner; no anonymous agents, no free-floating agents. The owner field is required because it's load-bearing for both access and accountability. Make it a foreign key with cascade behavior so the data model can't get into an orphaned state.

3. Issue per-agent credentials, never share. Each agent gets its own key (API key, OAuth token, whatever fits your stack). Two agents owned by the same human have two different credentials. Rotation on one doesn't affect the other. The cost is a slightly bigger credential store; the gain is real attribution.

4. Define the access propagation model. Pick one of: per-workspace (grant explicitly), inheritance (agents see what owners see), or hybrid (inheritance with per-workspace override). Inheritance is the right default for collaborative workspaces; per-workspace is right for high-stakes scopes that need explicit elevation. Document the choice in the API contract, not just in the implementation.

5. Make the audit log dual-keyed. Every event the agent emits records both the agent's principal id (the actor) and the owner's user id (the accountable principal). Queries can ask "what did Govind's agents do this week" without joining tables, and incident response can ask "show me everything attributable to this owner" without missing the agent half.

6. Wire the cascade. When the owner loses access to a workspace, their agents lose access in the same transaction. When the owner is deleted or deactivated, their agents are too. The cascade is the contract that keeps the inheritance model coherent — without it, the access graph drifts into orphaned-agent territory within a month.

The team that answers all six concretely has a real agent identity model. The team that answers four is shipping a delegate-flavored credential system. The team that answers two is reinventing the chat-running-as-user pattern with extra steps.

FAQ

What is AI agent identity?

AI agent identity is the distinct principal an AI agent uses to act on the platforms it touches. It's separate from any human's identity: the agent has its own principal id, its own credential, its own audit trail, its own scope of access. The agent has an owning human (accountability link), but its actions are attributed to the agent, not to the owner. This is distinct from "the agent uses the user's API key," which is the delegate pattern and gives the agent the owner's blast radius.

Why do AI agents need their own identity?

Three failure modes appear without it: trust (the human is credited or blamed for actions they didn't take), debugging (the audit log conflates the agent and the human, making investigations expensive), and scale (multiple agents under one user are indistinguishable). All three compound as agent usage grows. The fix is one-time architectural: per-agent principal, per-agent credential, per-agent scope.

How is an agent identity different from a service account?

A service account is org-owned, exists independently of any specific human, requires admin tooling to manage. An agent identity is human-owned, exists because someone specific runs it, can be managed by the owner. Service accounts were designed for org-owned cron jobs and integration glue; agent identities are designed for human-attached, frequently-rotating, owner-accountable agents. Using a service account for an agent works mechanically but breaks accountability: there's no specific human responsible.

What is signed-agent inheritance?

A pattern where every agent has a required owning human, and the agent automatically inherits access to whatever workspaces the owner has access to. Access flows down (owner → agent), accountability flows up (agent → owner). The pattern collapses (humans × agents × workspaces) permission management into just (humans × workspaces), because the agent half is computed.

How do I prevent an agent from acting outside its scope?

Per-agent permissions are the structural answer: each agent has explicit scope on what it can read, write, and call. Default-deny on everything outside the explicit scope. Plus a consent gate on irreversible operations (the agent proposes, a human or second agent confirms). See the dangerous-ops contract for the gate shape.

Can multiple agents share an identity?

They shouldn't. Sharing identity is sharing audit trail, which collapses the value of having identity at all. If two agents need the same access, give them two identities owned by the same human (or by a shared owner if that fits) — same access, distinct attribution. The marginal cost of an extra identity is near-zero; the value of distinct attribution scales with the number of agents.

What's the right way to rotate an agent's credential?

Owner-driven self-service. The owner generates a new key, the platform retires the old one within a short grace window (15 minutes is typical), the audit log records the rotation. No admin involvement for the owner's own agent. Admin involvement only for cross-cutting rotations (e.g., compromised root credential, mass rotation event).

Does giving an agent its own identity weaken security?

It strengthens it. The blast radius of a compromised credential is bounded to the agent's scope, not the owner's full access. The audit trail tells you exactly what the compromised agent did. Revocation is one row, not a password reset that logs out the human. The compliance team can answer "did an AI take this action" instead of leaving it ambiguous.

Where Dock fits

Dock implements the principal pattern, signed-agent inheritance, and dual-keyed audit. Every agent has an owning human (required field at creation), its own credential (revocable independently), and access derived from the owner's workspace memberships. Audit log rows carry both the agent's principal id and the owner's user id. The cascade is atomic: when an owner loses workspace access, their agents lose it in the same transaction.

This isn't an ideological choice. It's the shape that makes the operations we care about (collaborative workspaces, multi-agent teams, compliance review) actually work. The delegate pattern doesn't scale past a few agents; the service-account pattern doesn't fit human-attached agents; the principal-plus-inheritance pattern handles both directions without contradiction.

If you're building an agent platform and your audit log currently reads as "the user did everything," the architecture is the delegate pattern. Migration is a data model change plus a credential reissue: new Agent table with ownerUserId, new credentials per agent, cascade access changes through the owner link. We did this migration at Dock in late 2025 and it took about two weeks of focused work for a small team.

Read next

The five essays below dig into specific axes of the agent identity model.

• Why agents need their own identities — the operational case for the principal pattern, from the team's first month of running agents.
• Agents are principals, not delegated tokens — the framing argument and the seven design choices that follow.
• Signed-agent inheritance — the architectural deep-dive on owner-driven access propagation.
• Service accounts vs agent identities — the contrast and migration path.
• What's wrong with agents using human credentials — the anti-pattern walked through with concrete failure modes.
• Agentic AI architecture: the five layers nobody draws together — where identity sits in the broader stack (cross-cutting, with strong Layer 5 implications).