AI identity is emerging as a foundational enterprise architecture question. This paper examines design principles rather than prescribing a single identity technology, compliance framework, or implementation pattern.
Enterprise identity programs were built primarily around people, devices, applications, and workloads. Agentic AI introduces a new class of actor: software that can interpret objectives, select tools, retrieve information, call APIs, generate outputs, and in some cases initiate actions across multiple systems. That shift changes the identity problem.
The central enterprise question is no longer only whether an AI system can authenticate. It is whether an organization can establish a durable and reviewable record of which agent acted, under whose authority, with what permissions, using which tools, against which resources, and with what resulting activity.
Identity becomes part of the AI control plane
When an AI capability remains inside a bounded application, existing application identities may be sufficient. As agents become more autonomous and more interconnected, identity needs to operate across the full lifecycle of an agent: creation, registration, deployment, delegation, execution, suspension, rotation, and retirement.
This suggests an identity layer with several connected properties:
Persistent identity
An enterprise should be able to distinguish one agent from another across sessions, environments, and system boundaries. A display name is not enough. A durable identifier should remain stable enough to support policy, logging, investigations, and lifecycle management while still allowing underlying models, runtimes, and infrastructure to change.
Verifiable credentials
The system receiving a request needs a way to verify that the asserted identity is legitimate. Existing workload-identity approaches provide useful architectural precedent. For example, SPIFFE defines a standardized identity namespace for workloads and verifiable identity documents that can be cryptographically validated. AI-agent identity will not necessarily use the same implementation model, but the principle is relevant: identity should be machine-verifiable rather than inferred from application context alone.
Delegated authority
An agent often acts because a person, application, workflow, or another agent asked it to do something. Enterprises therefore need to represent not only the agent identity but the chain of authority behind the action. That chain can help answer whether the action was within the purpose, scope, and time window originally authorized.
Scoped access
Identity and authorization should remain separate but closely connected. An authenticated agent should not automatically receive broad access. Permissions should be constrained by task, resource, environment, transaction sensitivity, and business context. Short-lived credentials and least-privilege policies can reduce the impact of compromised or misdirected agents.
Revocation and lifecycle control
Enterprise identity is incomplete without the ability to suspend or revoke an agent. Organizations need a reliable way to terminate access when an agent is retired, compromised, misconfigured, superseded, or no longer approved for a particular use.
Identity must connect to evidence
Authentication alone does not create accountability. Organizations will also need activity evidence that connects identity to actions. Useful evidence may include the initiating principal, agent identifier, policy decision, model or runtime version, tools invoked, data sources accessed, external systems called, approvals obtained, timestamps, and resulting outputs or transactions.
The goal is not to log every token indiscriminately. The goal is to create enough structured evidence to support operational review, security investigation, governance oversight, and appropriate business accountability.
Five design principles for enterprise AI identity
1. Make identity independent of the user interface. An agent may move between channels and applications. Its core identity should not depend on where it appears.
2. Separate identity from capability. Knowing who or what an agent is should not imply what it is allowed to do.
3. Preserve delegation context. High-impact actions should be traceable to the human, system, workflow, or policy that authorized them.
4. Design for revocation before scale. Enterprises should be able to stop an agent or narrow its permissions rapidly without rebuilding surrounding systems.
5. Treat auditability as architecture. Evidence requirements should be designed into the identity and execution flow rather than added later as a reporting layer.
What changes for enterprise leaders
AI identity is likely to become a shared responsibility across security, identity and access management, application architecture, AI platforms, governance, risk, and business operations. No single team owns the full problem.
Organizations beginning to deploy agents can start by creating an inventory of agentic workloads, assigning accountable owners, defining unique identifiers, documenting delegated authority, constraining tool access, recording high-value actions, and establishing a revocation process. These steps can be implemented before a broader industry standard for AI-agent identity fully emerges.
Research view
The enterprise identity stack is expanding. Human identity, device identity, service identity, and workload identity will increasingly need to coexist with identities for autonomous and semi-autonomous software actors. The durable architecture will be the one that lets enterprises verify agents, limit their authority, reconstruct their activity, and terminate access with the same discipline expected for other privileged actors.
Selected references
- SPIFFE — Secure Production Identity Framework for Everyone
- SPIFFE Identity and Verifiable Identity Document
- NIST — AI Risk Management Framework
Research notice
New York AI Group® research is provided for general informational purposes and does not constitute legal, regulatory, cybersecurity, investment, or other professional advice.