In my last post, I used Mike Schwartz’s diagram, which decouples Identity from Access Management, to place the four dimensions of AIdentity Governance™: TRUST, CRED, PRIV, and BEHAVE. TRUST anchors the Identity side. It asks whether a principal has been vouched for, and whether that accountability chain still holds.

CRED completes the Identity side. It asks a narrower and more urgent question: can this principal prove it is who it claims to be, right now?

Mike Schwartz inspired me to diagram the four dimensions with Identity and Access split

What CRED actually asks

A credential is how an identity claim becomes verifiable. It isn’t enough that a credential was issued. It has to have been issued by a trusted authority, be currently valid, be bound to exactly one principal, and be presented by the principal it was issued to. And the cryptography underneath that binding has to still hold.

That last condition is the subject of a later post on PKI and post-quantum cryptography. The other four are enough for this post.

TRUST and CRED fail differently. A TRUST failure is an accountability chain that was never real, or has broken: a sponsor nobody verified, a model nobody can trace. A CRED failure is a presented identity artifact whose proof has escaped: a stolen key, a replayed token, a credential presented by something other than the principal it was issued to. Strong TRUST does nothing for a leaked API key. A perfect credential does nothing for an agent nobody vouched for.

In 20916, when I first wrote down how the TRUST, CRED, PRIV and BEHAVE relate, I drew them around a single user. That was where the world I identity was focused:

The four dimensions and their relationship to the user: TRUST establishes identity, CRED provides access, PRIV represents identity, BEHAVE maintains identity; CRED requires TRUST, and PRIV requires CRED

Each dimension does something different for the user. TRUST establishes identity, CRED provides access, PRIV represents identity, and BEHAVE maintains it. The red arrows matter most here: CRED requires TRUST, and PRIV requires CRED. A credential is only worth issuing to a principal TRUST has established, and a privilege is only worth granting to a principal that can prove its claim. CRED is the link in the middle of that chain.

Replace the user with an agent and every arrow still holds. What changes is how fast they have to be re-evaluated.

What’s in the CRED box

Two of Mike’s components sit squarely in CRED: Other MFA and Authn orchestration. Both prove a claim at the moment of access and decide how strong that proof needs to be. NIST SP 800-63B’s authenticator assurance levels, AAL1 through AAL3, are the familiar yardstick.

I added two components of my own, shown with dashed outlines: JWT and OIDC. Mike’s diagram doesn’t need them, because it’s an architecture of systems, and these are a format and a protocol. But from CRED’s point of view, they’re where most proofs of claim actually travel. A JWT is the signed envelope. OIDC is the protocol that fills it. OIDC’s claim structure also matters for more than authentication: it can carry posture signals, step-up context, risk scores, and agent-specific claims. That’s the context a policy enforcement point needs to respond to a change in one dimension with something more precise than a blunt deny.

Then there’s what CRED shares with its neighbors:

  • With TRUST: PKI, SPIFFE, WIMSE, and passkeys (FIDO2). Each pairs an anchor with the credential it issues. The TRUST post covered the anchor. The credential is CRED: what it’s bound to, how long it lives, and how it’s verified.
  • With PRIV: OAuth. A token proves a claim and carries the scope of what the bearer may do. For agents, that dual role turns out to be central.

Agents break issue, hold, present

Look at the two lobes of Mike’s Identity quadrant that carry credentials. The Human lobe holds passkeys, other MFA, and authentication orchestration. The Software lobe holds OAuth, SPIFFE, WIMSE, and Agentic. Those are two different credential models, side by side.

Human credentialing, and most non-person entity credentialing, was built on one assumption: a persistent principal. Issue a credential, the principal holds it, the principal presents it. PIV cards, certificates, passwords, and a service account’s API key all work this way. For NPEs, the industry mostly never got past shared secrets and static bearer tokens, which is why non-human identity has been the weakest link in most enterprises for years.

Agents don’t stretch that model. They break it:

  • An agent may exist for seconds.
  • It may spawn dozens of child processes, each needing to authenticate on its own.
  • It may call ten services in a single task.
  • A new instance may start for every invocation, with no memory of earlier credential exchanges.

A long-lived credential in that environment isn’t just awkward; it’s a liability. And agents add a risk service accounts never had. An API key in an agent’s context window is reachable by the agent’s own reasoning. It can be echoed into an output, captured in a trace, or pulled out by a prompt injection. A service account’s secret sits in a config file. An agent’s sits inside the thing an attacker is trying to talk to.

What CRED looks like for agents

Most of the pieces of the replacement exist today:

  • Workload identity is the primitive. SPIFFE issues short-lived, cryptographically attested identity documents (SVIDs) based on runtime context instead of pre-provisioned secrets. An agent’s credential should come from where it’s running, what task it was instantiated for, and who authorized that instantiation. The IETF WIMSE working group is standardizing how workload identities travel in service-to-service calls and in token exchange at security boundaries, which is exactly the shape of an agent’s tool calls.
  • Tokens are requested per operation. When an agent needs a tool, it requests a token scoped to that operation, at the moment it needs it. OAuth Rich Authorization Requests (RFC 9396) describe the operation precisely, short lifetimes limit the window, and proof-of-possession binding with DPoP (RFC 9449) means a stolen token is useless without the key it’s bound to.
  • Credentials end with the task. When the task completes, the credential is discarded. Nothing persists for an attacker to find later.
  • Agents never hold human credentials. No usernames, passwords, or session cookies. When an agent acts for a person, the pattern is delegated authorization: explicit consent, narrow scope, a short lifetime, and a cryptographic binding to the agent’s own workload identity. An agent logged in as you isn’t a delegation. It’s an impersonation nobody can audit.

This is why OAuth sits on the boundary with PRIV. In the agent pattern, the credential and the scope are issued together, per operation. CRED proves the claim, PRIV decides what the token says, and getting either one wrong undoes the other.

Every hop narrows

In the TRUST post, I said delegation has to be non-transitive: a sub-agent doesn’t inherit its orchestrator’s TRUST position. CRED is where that rule is enforced, in the token itself.

When an orchestrator delegates to a sub-agent, the sub-agent’s credential has to be scoped narrower than its parent’s. Every hop reduces scope; none preserves or expands it. And the chain has a depth limit. Without both, privilege propagates without bound through a pipeline of agents: the AI equivalent of a Kerberos golden ticket.

The standards here aren’t finished, but there’s a lot of activity. OAuth Token Exchange (RFC 8693) and GNAP (RFC 9635) are building blocks. UMA 2.0 is strong prior art for policy-governed delegation, but it was designed for a human delegating to a client, not for agent-to-agent chains. At the IETF, drafts on agent authentication, authorization, and delegation are arriving across several working groups, and agent delegation chains are now named in at least one working group charter. But no adopted draft yet defines scope reduction at every hop or a limit on delegation depth. Until one does, those are custom policy controls you have to build and enforce yourself.

CRED reaches across the split

Like TRUST, CRED is anchored on the Identity side but doesn’t stay there.

  • To PRIV, through OAuth. In the agent pattern, credential and scope are a single issuance.
  • To BEHAVE, through revocation. When BEHAVE confirms compromise, revoking the credential is one of the first responses, and in a multi-agent pipeline it has to reach every sub-agent too. The response is tiered: minor, explainable drift gets a session reset, not a revocation. Credential misuse gets revocation immediately. Short-lived credentials help either way. There’s less to revoke, and less time for a stolen one to matter.

What CRED still needs a place for

Read through CRED, the diagram has a few open slots:

  • Delegation chain governance: scope reduction and depth limits across multi-agent pipelines, still without a standard.
  • Secrets in agent context: an inventory of every long-lived secret an agent can reach. The target is zero.
  • Binding the credential to what the agent is. A workload credential says which workload is running. It doesn’t say which model, system prompt, or tool manifest is running inside it. Connecting the credential to the agent’s model provenance spans TRUST and CRED, and WIMSE, by design, leaves it out of scope.
  • Revocation at pipeline speed: when an orchestrator’s credential is revoked, its sub-agents’ credentials have to go with it, immediately.
  • Agents using human credentials: detecting it, not just prohibiting it. Agents that drive a browser or a desktop make this a live problem.

As with TRUST, these aren’t flaws in Mike’s architecture. They’re the parts of agent credentialing the industry is still building.

CRED data elements for the Master Agent Record

The TRUST post started a list of data elements a Master Agent Record should carry. Read for CRED, Mike’s boxes and my two additions suggest the next set:

  • SPIFFE and WIMSE: the agent’s workload identity type and the trust domain that issues it. TRUST records who vouches for that authority; CRED records what it issues.
  • OAuth: the token scope manifest, typical token lifetime, and proof-of-possession binding method (DPoP or mTLS).
  • JWT and OIDC: which issuers sign the agent’s tokens, with which algorithms, and which claims those tokens carry.
  • Other MFA, Authn orchestration, and passkeys: the assurance level required for the human approvals the agent depends on, from the sponsor’s authorization at instantiation to step-up for high-consequence actions, and whether a hardware-bound passkey meets it.

Add what the diagram leaves open:

  • Rotation and revocation: rotation policy, last rotation, and the revocation path, including how revocation reaches sub-agents. Vectors of Trust (RFC 8485) already treats credential management, “binding, rotation, and revocation,” as its own component of trust, separate from proofing and credential strength. It describes a category of lifecycle, though, not a record, and it predates delegation to agents.
  • Delegation: the depth limit and a record of the current delegation chain.
  • Static secrets: an attestation that the agent holds no long-lived secrets and no human credentials.
  • Cryptographic posture: whether each credential is classical-only, hybrid, or post-quantum.

If you’re starting from zero, the CRED equivalent of naming a sponsor for every agent is just as simple: find every long-lived secret an agent can reach, and start replacing them with credentials that end with the task.

Where this is going

That completes the Identity side. Next is PKI, the clearest case of one technology serving both TRUST and CRED, and what post-quantum cryptography does to each. Short-lived agent credentials turn out to have a quantum advantage. SAML turns out to have no migration path at all. After that, PRIV and BEHAVE on the Access side.

For the full framework, see the Framework page. For how all four dimensions hold up under post-quantum migration, see the white paper.