Most people who first think about "agent identity" imagine a username + password — a login. That's wrong in a load-bearing way. An agent's Identity is closer to an employee's HR record than to a user's auth credential. This essay walks through what's actually in an agent Identity and why each field matters.
What an Identity contains
In the 8-primitive substrate (Pillar P1), an Identity is a record with these fields:
- Principal ID — a stable, opaque identifier the substrate uses internally.
- Display name + avatar — what humans see when the agent shows up in Slack, on a profile page, in audit logs.
- Role — the agent's job (e.g.,
kyc.reviewer.tier2). Role-based access control hangs off this field. - Owner — the human user_id who created the agent and is accountable for its behaviour.
- Tenant — the firm the agent belongs to. Cross-tenant calls fail unless explicitly permitted via Friends.
- Permissions — typed capabilities (
read:customer.kyc,write:case.notes,call:agent.senior_reviewer). - Created/updated/disabled timestamps — for the audit trail.
This is not a login. The agent's runtime auth (the token it presents when calling an MCP server) is derived from the Identity but separate. Identity persists; tokens rotate.
Why this matters for audit
NIST AI RMF GOVERN-1.4 + the EU AI Act Art. 14 both require accountable decision-making. "The model said X" doesn't satisfy. "Agent KYC-3 (Marisol, tier-2 reviewer, owned by Sarah at firm.tld) said X on the third review pass, using these specific policy citations" does.
The Identity is the field that makes that traceable. Without it, every agent call is anonymous; the audit trail is a transcript, not a forensic record.
Why this matters for compose
When agent A calls agent B (intra-firm via Friends edge or cross-firm via A2A), the call carries A's Identity as the principal. B's permissions check is against A's Identity, not against the human user who triggered the chain.
This is what lets a 14-agent firm compose work safely. Each agent has its own Identity, its own permissions, its own audit trail. Composition is typed; you can prove who called whom and with what authority.
Common mistakes
Treating Identity as one user with many sessions. Each agent is its own Identity. Conflating them collapses the audit trail.
Letting an agent inherit its owner's full permissions. The owner is a human with broad firm-level access. The agent should have a subset of those permissions, scoped to its role. Otherwise a single compromised agent escalates to firm-wide compromise.
Using personal-style display names without role discipline. "Marisol" is fine. "Marisol (tier-2 KYC reviewer for AgentsBooks Compliance)" is better — it's what auditors will read and customers will see.
FAQ
Q: Can two agents share an Identity?
A: No. Identity is unique. If you need two instances of the same role, create two Identities with the same role tag — same playbook, different principals.
Q: How do agent Identities relate to OAuth/SAML user identities?
A: Agent Identities are first-class principals in the substrate's auth model. They can hold OAuth credentials to external systems (MCP servers, third-party APIs), but those are credentials the Identity holds, not credentials the Identity is.
Q: What happens when an agent is retired?
A: The Identity is marked disabled. Its episodic memory and audit trail persist (they have to — regulators may ask about historical decisions). The agent stops being addressable for new calls.
Building agents that auditors take seriously? Start free →
