AI agents need an identity that survives longer than a single session without turning that identity into a permanent credential. Those are different requirements, and enterprise architecture should separate them.
A persistent identifier answers “which agent is this?”
The Compute Passport model uses a persistent Compute Passport Identifier, or CPID, for each governed AI object. The identifier is non-secret and globally unique. It can represent an agent, model, workload, compute resource, tool, policy or evidence object while remaining stable across the lifecycle.
The value of persistence is continuity. Ownership, purpose, status, delegation, model binding, workload history and evidence can remain attached to the same governed object even when runtime credentials rotate.
Credentials should be short-lived, scoped and continuously revocable
A persistent identity should not imply persistent privilege. Runtime proof should be ephemeral: signed, audience-bound, time-limited and constrained to the approved task and environment. If the agent changes workload, destination, model, region or data boundary, the verification decision can change even though the CPID stays the same.
This separation reduces the need to use long-lived secrets as identity. It also creates a clean control point for suspension and revocation. The identity remains resolvable while the current proof can expire, be rejected or be replaced.
Trust depends on status, not a static certificate
A cryptographic credential is only meaningful if the receiving system can determine whether the identity is still trusted. Status therefore becomes an online control surface. An agent may be active, suspended, expired, retired or compromised, and enforcement points should be able to resolve that state before protected actions.
For higher-risk workflows, trust should include proof of the surrounding environment: the issuer, cryptographic key, workload image, region, compute context, policy binding and destination. A valid signature alone should not override a mismatch in operating context.
Key hierarchy separates long-term trust from runtime execution
A stronger design separates root trust, tenant issuance, passport signing and runtime keys. Root trust can remain offline or hardware protected. Tenant issuers define isolation boundaries. Passport keys sign identity and policy binding. Runtime keys provide ephemeral proof for a specific task or session.
This hierarchy supports rotation, separation of duties, compromise recovery and customer-specific trust boundaries without changing the identity semantics of the passport itself.
Persistent identity enables portable governance
Enterprises rarely run one identity, AI or cloud platform. A persistent identifier can provide continuity across Entra, Okta, AWS IAM, AI gateways, model platforms, Kubernetes, SIEM and GRC integrations while each domain retains its own enforcement authority.
The result is not a universal login. It is a common way to ask whether the same governed AI actor is still approved, still inside its authority boundary and still operating with verifiable proof.
Identity should be durable. Privilege should not be.
That distinction is central to AI identity infrastructure. Keep the identity stable enough to preserve ownership and evidence. Keep the credential temporary enough to enforce least privilege and rapid revocation. The combination makes machine identity more accountable without turning it into standing access.