Give every production AI agent a distinguishable machine identity, accountable human owner, documented purpose, and least-privilege access. Separate autonomous application permissions from access delegated by a user. Keep credentials out of prompts, issue short-lived audience-bound tokens, log the agent and human actor separately, and disable the identity when its workflow ends. Agent Cards and display names aid discovery, but directory-backed identity and authorization enforce access.
Tech
Give every production AI agent a distinguishable machine identity, accountable human owner, documented purpose, and least-privilege access. Separate autonomous application permissions from access delegated by a user. Keep credentials out of prompts, issue short-lived audience-bound tokens, log the agent and human actor separately, and disable the identity when its workflow ends. Agent Cards and display names aid discovery, but directory-backed identity and authorization enforce access.
Reviewed July 30, 2026: Microsoft Entra Agent ID documentation was changing rapidly and product-specific licensing may change. The architecture principles below also use the February 2026 NIST NCCoE concept paper, which is a concept paper, not a completed identity standard.
At a glance
• Do not let multiple agents act through one shared employee account.
• Create a distinct identity for each security boundary that needs separate permissions or evidence.
• Record a sponsor or owner who is accountable for access and lifecycle.
• Choose autonomous, delegated, or user-like identity deliberately.
• Grant permissions to business capabilities and resources, not broad platform access.
• Log the agent identity, user identity, tool, policy, approval, and outcome.
Identity is more than an agent name
An agent can have several identifiers that serve different purposes:
• A product or inventory identifier tells operators which agent exists.
• An A2A Agent Card advertises a remote agent’s skills, endpoints, and security requirements.
• An application or service principal authenticates software to an identity provider.
• An access token represents authorized access to a particular resource.
• A user identity may be the subject when an agent acts on someone’s behalf.
These identifiers should be linked, not conflated. A signed Agent Card can help verify that metadata came from a claimed publisher, but it does not grant CRM access. A service principal can obtain a token, but it does not describe an agent’s business skills. A display name improves inventory, but it is not a security boundary.
The NIST NCCoE concept paper frames software and AI agent identity and authorization as a cross-organization challenge. Its presence is useful evidence that the problem extends beyond one vendor, but implementers should not describe the concept paper as a normative NIST control framework.
Identity architecture and mechanics
Start by choosing the acting mode.
Autonomous access gives the agent permissions directly. A scheduled reconciliation agent might read invoices and create exceptions without a user present. Its identity should appear as the actor in access and audit records.
Delegated access lets the agent act on behalf of an authenticated user. The agent should receive only the delegated rights needed for the requested task, and records should preserve both the user subject and agent actor.
User-like access is needed only when a system requires a user account, mailbox, chat presence, or equivalent resource. It creates additional lifecycle and licensing obligations and should not be the default workaround for an application that lacks proper workload authorization.
Microsoft’s Agent ID overview distinguishes agent identities from human and conventional application identities. Its agent identity architecture uses agent identity blueprints to create related agent identities. The blueprint holds credentials and can obtain tokens on behalf of agent identities, while each agent identity can carry its own permissions and audit identity.
That separation supports scalable creation, but it also creates a concentration risk: compromise of a blueprint’s credentials can affect identities created under it. Blueprint boundaries should therefore reflect security boundaries, not only development convenience.
Service principals, scopes, and resources
A service principal is a directory representation of an application or workload. It is useful when an agent is stable, centrally managed, and acts as software. Agent-specific identity products add metadata, sponsor relationships, creation patterns, and audit classification for more dynamic workloads.
Permission design should answer four questions:
1. Which resource can the agent reach?
2. Which operations can it perform?
3. Is it acting autonomously or for a user?
4. Which contextual conditions must be true?
“CRM access” is not a useful scope. Prefer capability-oriented rights such as reading assigned accounts, creating draft tasks, or updating a defined field on records within the agent’s territory. Enforce record-level permissions in the resource system; an OAuth scope alone is rarely sufficient.
Identity decision table
Workload: Nightly data-quality check; Identity pattern: Autonomous agent or workload identity; Key restriction: Read data and create exception records only
Workload: Sales assistant updating the current user’s deal; Identity pattern: Delegated access; Key restriction: Preserve user subject and agent actor
Workload: Temporary research worker; Identity pattern: Ephemeral agent identity; Key restriction: Expire identity and artifacts with the task
Workload: Agent that needs mailbox or Teams presence; Identity pattern: Agent-linked user account where supported; Key restriction: No privileged admin role; explicit lifecycle
Workload: Multi-tenant SaaS agent; Identity pattern: Publisher blueprint plus tenant-local identity where supported; Key restriction: Tenant isolation and local consent
Workload: Development prototype; Identity pattern: Separate non-production identity; Key restriction: No production data or reusable production secret
Security and governance
Every identity needs an owner, purpose, environment, data classification, permission set, creation date, review date, and retirement condition. An “AI team” mailbox is not enough ownership. Name a role or sponsor capable of approving access and responding to incidents.
Apply least privilege at multiple layers:
• identity provider permissions;
• application and record-level access;
• MCP server and tool allowlists;
• network destinations;
• model-visible data;
• action-level approval.
Use managed or federated credentials where the platform supports them. If a secret is unavoidable, store it in a managed secret store, rotate it, and prevent it from entering model context. Agents do not need to know bearer tokens; the execution layer attaches credentials after the model selects an authorized action.
Audit records should answer:
• Which human initiated or sponsored the task?
• Which agent planned and requested the action?
• Which identity authenticated?
• Which policy allowed the operation?
• Which tool and resource were used?
• What arguments materially affected the action?
• Was human approval required and obtained?
• What changed in the target system?
Distinct identities also make incident containment possible. Security teams can disable one agent, revoke a permission, or quarantine one blueprint class without disabling an employee or every automation.
Implementation checklist
• [ ] Inventory agents, subagents, service accounts, shared accounts, and API keys.
• [ ] Assign a stable identifier, purpose, owner, and environment to each agent.
• [ ] Decide autonomous, delegated, or user-like acting mode.
• [ ] Create separate identities for separate security boundaries.
• [ ] Map each identity to exact resources and business capabilities.
• [ ] Remove shared employee credentials from unattended workflows.
• [ ] Use federated or managed credentials where supported.
• [ ] Bind tokens to the intended audience and keep them short-lived.
• [ ] Keep credentials outside prompts, memory, tool output, and normal logs.
• [ ] Enforce record and tenant permissions in downstream systems.
• [ ] Add action confirmation for financial, destructive, or external changes.
• [ ] Log human subject, agent actor, identity, policy, tool, and outcome.
• [ ] Review permissions after workflow or organizational changes.
• [ ] Disable identities and revoke credentials automatically at end of life.
• [ ] Test compromise, revocation, orphaned sponsor, and failed token scenarios.
Limitations and change risk
There is not yet one universal agent identity object recognized by every cloud, SaaS product, and protocol. Directory identity, workload identity, Agent Cards, payment credentials, and application inventory remain separate layers.
Microsoft Entra Agent ID is a concrete vendor implementation, not a cross-platform standard. Its terminology, licensing, integrations, and migration behavior can change. The official service principal comparison should be rechecked before making product-specific decisions.
Identity also cannot make an unsafe workflow safe by itself. A correctly authenticated agent can still call an overpowered tool, mishandle untrusted content, or make a poor decision. Identity must connect to authorization, tool policy, evaluation, and incident response.
For a practical operating model around these controls, read AI agent governance for SMBs.
FAQs
Does every subagent need its own identity?
Not necessarily. Create a distinct identity when a subagent crosses a separate trust boundary, needs different permissions, has a different owner, or must be distinguishable in audit and containment.
Can an agent use a normal employee account?
It should not use a shared employee account for unattended work. Delegated access can preserve the user as subject while identifying the agent as actor. User-like agent accounts should be explicit and constrained.
Is an A2A Agent Card an identity credential?
No. It is discovery metadata and can optionally be signed for integrity and origin. Access to resources still requires authentication and authorization through an identity system.
What is the difference between an agent identity and a service principal?
A conventional service principal represents an application workload. Agent-specific identity systems can add agent classification, sponsors, blueprints, delegated acting patterns, lifecycle behavior, and clearer agent audit records.
How often should agent access be reviewed?
Review on a fixed schedule and whenever the workflow, owner, model, tools, data sources, or target permissions change. Ephemeral agents should expire automatically instead of waiting for periodic review.
Get a 20-Minute AI Workflow Audit
AI Operator can map one workflow’s human subject, agent actor, credentials, resources, scopes, approval points, and audit evidence before access expands.