Principle 1: Agent Identity Is Mandatory

This is the first in a series exploring the 12 non-negotiable principles from our Agent Runtime Governance whitepaper. Each post dives into a single principle — why it matters, where organizations get it wrong, and what good looks like.

---

Here's a question every security leader should be asking right now: how many AI agents are operating in your enterprise today?

Not how many you approved. Not how many your AI team deployed. How many are actually running is the question — across engineering, product, research, operations, and every team that discovered they could spin one up with an API key and a prompt?

Most organizations can't answer this question. And the reason is simple: their agents don't have identities.

The Service Account Trap

When organizations first deploy AI agents, they almost always take the path of least resistance: run the agent under a service account, give it an API key, and connect it to the systems it needs.

This works — until it doesn't.

A service account tells you that something authenticated. It doesn't tell you what authenticated and for what reason. Was it the market research agent your data team deployed last month? The customer support agent your product team is prototyping? A rogue agent someone spun up to scrape internal wikis? The service account doesn't know. The API key doesn't care.

Now multiply this across an enterprise. Dozens of teams. Hundreds of agents. All sharing a handful of service accounts and API keys. Your audit log shows a steady stream of API calls from svc-ai-agent-prod. Which agent made which call? Why? On whose authority? You can't tell. The log is technically complete and practically useless.

This is the identity gap — and it's the first thing that breaks when organizations try to govern their AI agents.

Why AI Agents Need Their Own Identity Model

AI agents are not users. They don't log in, navigate a UI (unless designed to do so), and log out. They operate continuously, maintain state across sessions, chain actions autonomously, and delegate to sub-agents. They need an identity model built for what they are.

An agent identity is not a username. It's a structured set of attributes that answers four fundamental questions:

Who is this agent? A stable, unique identifier — an agent_id — that persists across sessions and restarts. Not a session token that expires. Not an IP address that changes. A permanent identifier that you can trace through every audit log, every incident investigation, every compliance review. This identifier must never be reused. When an agent is decommissioned, its ID is retired, not recycled.

What kind of agent is it? An agent_type that describes the agent's role in your architecture — planner, executor, observer, reviewer, coordinator. This matters because different agent types should have different authorization profiles. A planning agent that reasons about strategy shouldn't have the same permissions as an executor agent that modifies production systems. Type is the first layer of context that your authorization policies can evaluate.

Which version is running? An agent_version that ties the running agent to a specific codebase, model, and configuration. When an agent's behavior changes — because you updated its model, changed its prompt, or modified its tool access — the version changes. This is critical for three reasons: traceability (understanding what code produced a given action), rollback (reverting to a known-good version when something goes wrong), and behavioral comparison (detecting drift between versions).

Who is accountable? An owner field that maps every agent to a team, service, or business unit. Not the person who wrote the prompt. Not the cloud account that hosts it. The organizational entity that is responsible for this agent's behavior. When an agent does something unexpected, you need to know who to call. When a compliance review asks "who approved this agent?", you need an answer.

Self-Asserted Identity Is No Identity

Here's where most implementations go wrong: they let agents identify themselves.

An agent that declares "I am agent-42, a research assistant" is providing a self-asserted identity. It's the equivalent of someone walking into your office, handing you a business card they printed themselves, and expecting full access to your systems. You wouldn't accept that from a person. Don't accept it from an agent.

Agent identity must be cryptographically verifiable. The identity is issued by a trusted authority — an identity provider that your governance infrastructure recognizes. The agent presents credentials that can be validated independently. The governance layer checks those credentials on every action, not just at session start.

This isn't a theoretical concern. In a multi-agent system, agents communicate with each other. An agent might receive a request from another agent claiming to be a supervisor with elevated permissions. Without cryptographic verification, there's no way to distinguish a legitimate supervisor agent from a compromised agent impersonating one.

The Agent Registry

Identity alone isn't enough. An authenticated agent is a known agent, but not necessarily an authorized agent.

Enterprise agents should be registered in a centralized agent registry before they are permitted to operate — the same way employees are onboarded before they receive access credentials. The registry is the authoritative source of truth for which agents exist, what they're approved to do, and what their current trust state is.

Registration means:

• The agent has been vetted and approved through whatever governance process your organization requires
• Its capabilities have been reviewed and scoped
• Its owner has been identified and has accepted accountability
• Its identity credentials have been issued by your trusted authority

An unregistered agent is, by definition, an ungoverned agent. It might be benign — a proof of concept that someone forgot to formalize. Or it might be the early stage of a security incident. Either way, your governance infrastructure should treat it the same way: no registration, no execution.

What Happens Without Agent Identity

The consequences of operating agents without proper identity aren't hypothetical. They're playing out right now in enterprises across every industry:

You can't revoke access for an agent you can't identify. When a security incident occurs and you need to shut down a compromised agent, you need to know which agent to target. If fifty agents share the same service account, revoking that account shuts down all of them — including the forty-nine that are operating correctly.

You can't investigate incidents involving anonymous agents. Your SIEM shows anomalous behavior from an API key. Which agent? What was it trying to do? Who deployed it? Without identity, incident response becomes guesswork. You're correlating timestamps and hoping for the best.

Your compliance posture is theater. Auditors will ask: what AI agents are operating in your environment? What are they authorized to do? Who approved them? If your answer is "we don't have a complete inventory," the audit finding writes itself.

You can't enforce least privilege. Without identity, every agent gets the same permissions — whatever the shared service account provides. There's no way to give a research agent read-only access while giving an operations agent write access. The service account is either on or off.

You can't detect shadow agents. If legitimate agents don't have identities, you can't distinguish them from illegitimate ones. Every agent looks the same: an anonymous process making API calls. Shadow AI thrives in this environment.

What Good Looks Like

An enterprise with proper agent identity has:

• A complete inventory of every agent operating in the environment, updated in real time as agents are deployed, modified, and decommissioned
• Unique identification of every agent action in every audit log, traceable back to a specific agent, version, and owner
• Granular access control based on agent identity, type, and trust state — not shared credentials
• Instant revocation capability — isolating a specific agent without disrupting others
• Provenance tracking — understanding not just what an agent did, but which version of which agent, deployed by which team, operating under whose authority

This is the foundation everything else builds on. You can't enforce authorization policies for agents you can't identify. You can't audit actions you can't attribute. You can't govern what you can't see.

Agent identity is Principle 1 because without it, Principles 2 through 12 are impossible.

---

This post covers Principle 1 from our whitepaper, 12 Non-Negotiable Principles for Agent Runtime Governance. The whitepaper defines all 12 principles across three layers — Foundations, Execution, and Operations — plus a 5-level maturity model and practical steps to get started. Download the full framework here.

Need to design an agent identity model for your environment? Our Agent Authorization & Runtime Control Architecture engagement helps enterprise teams design agent identity, verifiable registration, and trust lifecycle management tailored to their infrastructure. Download the one-pager (PDF) or discuss an engagement.