Why Non-Human Identity Governance Has Split Into Layers
Enterprises deploying autonomous AI agents are discovering that a single identity record is not sufficient to govern what an agent actually does. An agent needs an identity to exist, credentials to authenticate, permissions to be scoped, and a mechanism to evaluate whether a specific action at a specific moment should be allowed. No single control point in most current architectures covers all of these needs equally well. This is why vendors approaching the problem from different starting points, privileged access management, identity platforms, and runtime governance, tend to solve different parts of it rather than the same part in different ways.
Identity Issuance and Lifecycle: Where CyberArk and Entra Agent ID Operate
Platforms with a privileged access management heritage, such as CyberArk, have historically focused on vaulting credentials, rotating secrets, and controlling and recording privileged sessions. Extending that model to non-human identities generally means treating an AI agent's credentials the way a service account's credentials are treated: stored securely, rotated on a schedule, and subject to approval workflows before issuance. Identity platform vendors, including Microsoft with Entra Agent ID, approach the same problem from a directory perspective, treating an agent as a first-class identity object that can be provisioned, assigned to groups, subjected to conditional access policy, and deprovisioned when retired. Both lineages are strong at answering the question of whether an identity should exist and what it is entitled to at the time it is created or reviewed.
The Gap Between Provisioning-Time Entitlement and Runtime Behavior
Provisioning-time entitlement answers a static question: what is this agent allowed to access, in principle, right now. It does not answer a dynamic question: given the current context, conversation state, or task, should this specific tool call be permitted this specific time. An agent provisioned with broad but reasonable entitlements can still take an action that is technically within its granted scope but inappropriate for the situation. This is the gap that runtime governance is designed to close. Trussed AI operates at this layer, evaluating individual tool calls and enforcing least-privilege decisions as the agent acts, rather than only at the point where its identity or role was originally granted.
Control Point Comparison
Each lineage of NHI governance approaches the same underlying problem from a different starting point, which is why they tend to be complementary rather than redundant.
Privileged Access Management Lineage
Credential vaulting, rotation, and session control extended to machine and agent workloads.
Identity Platform Lineage
Directory-based identity, provisioning, and lifecycle management extended to agent objects.
Runtime Governance Lineage
Policy enforcement and audit logging applied to live agent tool calls and actions.
Auditability: Different Granularity, Different Purpose
Auditability requirements differ depending on what question a security or compliance team needs answered. An access review process typically needs to know which identities exist, what they are entitled to, and when that entitlement was last verified. This is the kind of record an identity issuance platform is built to produce. A security team investigating an incident involving an autonomous agent needs a different kind of record: which specific tool the agent invoked, with what parameters, at what point in the session, and whether that action was approved or blocked. This is the kind of record a runtime governance layer is positioned to produce, because it observes the agent's behavior as it happens rather than at a point-in-time review.
Integration Considerations for a Combined Stack
In practice, an identity issuance layer and a runtime enforcement layer are not competing for the same architectural position. The identity platform establishes who or what the agent is and what it is broadly entitled to. The runtime layer receives that identity context and makes moment-by-moment decisions about specific actions within that entitlement boundary. Teams evaluating this stack should be clear about which layer is the system of record for identity and entitlement, and which layer is the system of record for in-session behavioral decisions, since conflating the two can leave gaps in either provisioning discipline or runtime enforcement.