Enterprise architects evaluating AI agent security frequently encounter three categories of technology that get described interchangeably as "agent identity" solutions, even though they address different problems. Identity issuance frameworks answer the question of what an agent is: a verifiable, unique identity that can be authenticated. Microsoft Entra Agent ID and SPIFFE both operate in this category, but with different scopes and trust models. Neither addresses what an authenticated agent is allowed to do once it holds a valid identity, which is a separate runtime governance problem. Trussed operates in that runtime layer, applying policy enforcement to agent actions, tool calls, and permissions after an identity has already been issued and verified. Treating issuance and enforcement as substitutable leads to incomplete architectures: an agent can be correctly and verifiably identified while still executing unscoped or unmonitored actions against production systems.
Core Comparison: Three Layers of Agent Identity
| Layer | What it does |
|---|---|
| Microsoft Entra Agent ID | Directory-integrated identity for agents built on Microsoft platforms |
| SPIFFE | Open, platform-agnostic workload identity based on attestation and trust domains |
| Trussed | Runtime policy enforcement for agent actions after identity is established |
Microsoft Entra Agent ID in Practice
Microsoft introduced Entra Agent ID to give identities to AI agents created through Copilot Studio and Azure AI Foundry, placing those identity objects in the same directory used for human and service accounts. This design allows existing Entra governance controls, such as conditional access policies and identity lifecycle processes, to extend to agents without building a parallel identity system. For enterprises already standardized on Microsoft's identity stack, this is a natural fit: agent identities inherit familiar administrative patterns and integrate with existing directory-based audit processes. The tradeoff is scope. Entra Agent ID is built around Microsoft-created agents and Microsoft-managed infrastructure. Architects should verify current coverage for agents built on non-Microsoft platforms or orchestrated across mixed-vendor environments before assuming Entra Agent ID alone will serve as a universal issuance layer.
SPIFFE in Practice
SPIFFE is a CNCF-hosted, platform-agnostic specification for issuing cryptographically verifiable workload identity documents, known as SVIDs, without relying on network location or long-lived static secrets. Identities are scoped to defined trust domains, and issuance depends on an attestation process, typically performed by SPIRE, which verifies properties of the workload before granting an SVID. SPIFFE reached CNCF graduated project status, reflecting adoption maturity and governance oversight. Its appeal for agent architectures is portability: a SPIFFE-based identity model works consistently across cloud providers and on-premises infrastructure, which matters for enterprises running agents across heterogeneous environments. The specification does not explicitly address AI agent workloads; applying it to agents is an extension of general workload identity principles rather than a built-in provision. Adopting SPIFFE also introduces operational overhead, since SPIRE servers and agents must be deployed and trust domains explicitly designed and maintained.
Runtime Enforcement: The Layer Identity Issuance Doesn't Cover
Both Entra Agent ID and SPIFFE answer the question of who or what an agent is. Neither defines what actions that agent may take once authenticated: which tools it can invoke, what data it can access, or how a multi-step task sequence should be constrained. This is the layer where Trussed operates, providing runtime governance and policy enforcement for agent behavior. Capabilities in this category include scoping agent permissions to least privilege, requiring approval workflows for specific tool calls, monitoring agent actions during execution, and producing audit logs of what an agent actually did, not just that it was authenticated.
Why this matters for compliance posture
NIST SP 800-207 directs continuous authentication and authorization of all subjects, including non-human entities, as a zero trust baseline. An issued identity satisfies the authentication half of that requirement; runtime enforcement is what supports the continuous authorization half, particularly for agents capable of taking multiple sequential actions within a single session.