Problem
Teams no longer just connect people to software. They connect agents to tools, data, calendars, CRMs, repositories, databases, browsers, and internal systems.
Risk appears when the agent acts as a blurry extension of someone: it uses a user’s tokens, shared credentials, inherited permissions, and logs that do not distinguish whether an action was human, automatic, or delegated.
Without its own identity, the agent becomes a phantom account. It can generate value, but it can also leave a company without real traceability.
Thesis
Agent Identity will be an infrastructure layer, not a security detail.
Every serious agent needs an operational passport: identity, owner, purpose, authorized tools, permissions, limits, expiration, execution history, and revocation mechanism.
The question is no longer “which model does it use.” The question is “who is this agent within my organization.”
Framework
An agent passport must include seven fields:
- Owner: person or team responsible.
- Mandate: task for which it exists.
- Scope: systems, data, and actions allowed.
- Credentials: its own tokens, not shared keys.
- Expiration: date or condition for expiry.
- Trace: history of tool calls, decisions, and outcomes.
- Revocation: simple way to turn off permissions.
Mini‑case: a finance agent reconciles invoices. If it acts with a person’s account, any error looks human. If it has its own identity, limited permissions, and a monthly expiration, audit can distinguish delegation, action, and responsibility.
Measurable signal: percentage of active agents with owner, scope, own permissions, and review date.
Stance: an agent without identity should not have persistent permissions.
Why it matters now
MCP already treats authorization as a formal part of the protocol, relying on OAuth 2.1 to separate clients, resource servers, and consent flows. A2A pushes a complementary idea: agents that discover, describe capabilities, and collaborate via visible contracts. OpenAI, in its practical guide to agents, insists on guardrails, human supervision, and safeguards for tools.
The direction is clear: agents stop being “chat sessions” and start looking like operational entities.
That requires identity. Not philosophical identity. Administrative identity.
Anti‑example
“The agent uses the operations team’s API key.”
Works for a demo. Fails for production. You don’t know what permissions it really needs, who approved them, which action belongs to the agent, or how to revoke without breaking the whole team.
Protocol (3 steps)
- Inventory active agents. Include scripts, GPTs, workflows, MCP clients, copilots, and automations with LLM.
- Assign minimal identity. Owner, purpose, tools, permissions, logs, and review date.
- Eliminate shared credentials. If you can’t do it all at once, start with agents that have side effects.
| Field | Question | Risk if missing |
|---|---|---|
| owner | who is accountable | nobody corrects |
| mandate | why it exists | scope creep |
| credential | how it accesses | blurry audit |
| expiration | when it is reviewed | zombie permissions |
| trace | what it did | inexplicable incident |
Related
- Tool Registry: the new risk map for enterprise agents
- Output Verification Layer: the invisible insurance for production agents
- MCP in enterprise: the standard that prevents agent chaos
Sources consulted
- MCP Authorization specification
- A2A protocol specification
- OpenAI: A practical guide to building agents
Next step
Choose three agents that already use real tools. Create their operational passport in a table and highlight in red any permission lacking an owner, expiration, or trace.
Translated from the Spanish original with AI assistance and reviewed for accuracy. Read the original in Spanish.