Mike Schwartz of Gluu recently shared a diagram arguing that Identity and Access Management are very different problems, each large and complex in its own right, and that it may be time to decouple them. His diagram places four quadrants side by side: Identity, Access Management, Governance, and Observability. It also splits Identity into three lobes: Organization, Human, and Software.

I think he’s right. His diagram also gave me something I’ve wanted for a while: a way to draw the four dimensions of identity governance I first proposed at CISA in 2016, TRUST, CRED, PRIV, and BEHAVE.

The four dimensions fit the split

Identity and Access separate cleanly along the four dimensions:

  • The Identity side is TRUST and CRED. TRUST asks whether an entity has been vouched for and whether that chain still holds. CRED asks whether it can prove it is who it claims to be, right now.
  • The Access side is PRIV and BEHAVE. PRIV asks what the entity is permitted to do. BEHAVE asks whether it is acting consistently with why it exists.

Here are the components from Mike’s diagram, placed into the four dimensions. I’ve added two of my own, JWT and OIDC, shown with dashed outlines:

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

Most of Mike’s components land cleanly in one dimension. GLEIF and registries are TRUST. Other MFA and authentication orchestration are CRED, joined by JWT and OIDC, the token format and protocol most proofs of claim actually travel in. Policy authoring, authorization, IGA, and PAM are PRIV. SIEM, threat detection, and session recording are BEHAVE.

His Governance quadrant doesn’t get a dimension of its own, and that’s deliberate. Capability inventory and continuous evidence are how you show a TRUST position still holds. Continuous compliance is PRIV. The telemetry dashboard is BEHAVE. Mike makes a sharp point about this quadrant: governance requires risk management. In the four dimensions, that risk judgment is made per dimension and recorded in one place, the Master Agent Record at the center of the diagram.

The dimensions depend on each other

The grey boxes are the most interesting part of the diagram. They hold the components that don’t fit in a single dimension, and every one of them sits on a boundary:

  • PKI, SPIFFE, WIMSE, and passkeys (FIDO2) span TRUST and CRED. Each pairs an anchor (a CA hierarchy, a trust domain, a hardware binding) with the credential it issues.
  • OAuth spans CRED and PRIV. A token proves a claim and carries the scope of what the bearer may do.
  • ITDR spans BEHAVE and PRIV. It detects a compromised or misused identity, and its response is usually to cut sessions or reduce privileges.
  • Shared Signals connects BEHAVE back to TRUST. Mike notes that Shared Signals doesn’t fit anywhere else in his diagram. I think that’s because it carries the feedback loop: what BEHAVE observes changes what TRUST can assert.

That’s why I call these dimensions rather than layers. A layer is where a system lives. A dimension is a question you have to keep answering about every principal, wherever its signals show up. Decoupling Identity from Access is the right architectural call, but it doesn’t make the dimensions independent. Weakness in one undermines the others. A strong credential doesn’t make up for a sponsor nobody verified. A clean set of permissions doesn’t make up for a delegation chain that has grown too deep.

The dependence runs in both directions. When BEHAVE detects drift outside an agent’s declared purpose, the right response isn’t a blunt shutdown but a targeted one: reduce scope (PRIV), revoke the credential if the behavior points to compromise (CRED), and lower or zero the agent’s TRUST position until its sponsor reviews it. Every dimension is recalibrated from the evidence another one produced.

Decoupling also raises the stakes. Once Identity and Access Management are separate systems, nothing holds a principal’s governance together by default. The four dimensions supply the common questions every part of the architecture has to help answer.

TRUST is the anchor of Identity

Everything downstream depends on TRUST. CRED proves a claim, but the claim is only worth proving if someone accountable stands behind it. PRIV grants scope, and BEHAVE judges conduct, both on the assumption that the principal is who the Identity side says it is. That makes TRUST the place to start.

Two questions inside the Identity quadrant

Mike’s Identity quadrant holds both TRUST and CRED. That makes architectural sense, since both sit upstream of every access decision. But they fail differently and are governed differently, and his own boxes show the split:

  • Mostly TRUST. GLEIF, registries, and the trust anchors of PKI. These answer “who stands behind this?” GLEIF is the clearest example on the page: a global, verifiable answer to which legal organization an identity resolves to.
  • Mostly CRED. Other MFA and authentication orchestration. These prove a claim at runtime.
  • Both. PKI is a CA hierarchy (TRUST) that issues certificates (CRED). It’s the clearest case of one technology serving both dimensions, and I’ll drill down into it in its own post after TRUST and CRED. SPIFFE and WIMSE work the same way: a trust domain, backed by an issuing authority (TRUST), issues workload credentials (CRED). Both standards define precisely how to validate what that authority issues, but neither says who vouches for the authority itself. That question is left to the deployment, which makes it a TRUST question. And hardware-bound passkeys, which are FIDO2 credentials, also anchor TRUST, because a synthetic identity can’t reproduce a hardware binding it was never issued.

That last point matters more each year. AI-generated documents and synthetic biometrics are getting good enough to beat traditional identity proofing. A credential can be perfectly valid while the accountability chain behind it was broken from the start.

The three lobes are three kinds of assurance

Mike’s three Identity lobes line up closely with how I break TRUST posture into components:

  • Organization is the anchor every accountability chain eventually resolves to.
  • Human is Human Identity Assurance: the strength of the identity claim for the person at the top of that chain.
  • Software covers both Non-Person Entity Assurance (workloads, service accounts, devices) and Agent Identity Assurance.

That last pairing is where I’d push. Mike places Agentic as one box in the Software lobe, next to OAuth and SPIFFE. Agents belong in this picture, and it’s good to see them named. But in the four dimensions, an agent isn’t a component; it’s a kind of principal all four dimensions apply to. And it has TRUST attributes no traditional NPE has, which is why I treat agent assurance as its own component:

  • A named human or organizational sponsor. Not another agent. The chain has to resolve to a person who owns the deployment decision and will answer for what the agent does.
  • Verified model provenance. Which foundation model, what fine-tuning, and whether the system prompt and tool manifest in production match what was approved. This is the AI-era equivalent of a software bill of materials. Without it, an agent has no established TRUST position, however strong its credentials look.
  • Non-transitive delegation. A sub-agent doesn’t inherit its orchestrator’s TRUST position. Every hop narrows what’s granted, and the chain has a depth limit.

None of these is a credential, and none appears in the diagram yet.

TRUST reaches across the split

TRUST is anchored on the Identity side, but it doesn’t stay there. Mike places Federation Mgt in Access Management and describes it as deciding which issuers you trust to issue which kinds of tokens with which claims. That’s a TRUST decision, which is why the diagram places it in TRUST. And through Shared Signals, what BEHAVE and ITDR observe on the Access side flows back to change a principal’s TRUST position.

That’s why TRUST can’t be certified once at deployment and assumed to hold. For an autonomous agent, it has to be re-evaluated continuously, partly from what the Access side sees the agent doing.

What TRUST still needs a place for

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

  • Identity proofing at establishment, where synthetic identity attacks land
  • A named sponsor requirement for every non-human principal
  • Model provenance for agents
  • Host integrity as a gate. A perfectly attested agent on a compromised host tells you nothing.
  • Delegation depth limits for multi-agent pipelines

None of this is a criticism of Mike’s diagram. His diagram is an architecture: it says where systems live and which ones should be decoupled so they can evolve independently. My four dimensions are a framework: the continuous assertions every enterprise must be able to make about every principal. Put them together and each fills a gap in the other. The diagram gives the dimensions concrete homes, the dimensions trace the dependencies between the diagram’s parts, and together they make the gaps visible. The missing boxes aren’t flaws in the architecture. They’re the parts of agent governance the industry hasn’t built yet.

From framework toward a governance model

A framework says what must be true. A governance model also says who decides, how often, and where the evidence lives. For agents, I see the Master Agent Record as the bridge: the governed artifact that records all four dimensions for an agent, in a form a named sponsor can review and an auditor can check.

Mike’s diagram suggests where to extend it. Read for TRUST, several of his boxes point to specific data elements a MAR should carry:

  • GLEIF: a verifiable organizational identifier for the agent’s owning organization, so the accountability chain ends at a legal entity rather than a name in a spreadsheet.
  • Passkeys: the sponsor’s authenticator binding. Is the human at the top of the chain anchored to a hardware-bound credential?
  • Federation Mgt: which issuers’ assertions about this agent will be accepted, and which claims each may make.
  • SPIFFE and WIMSE: the agent’s trust domain and issuing authority, the organization accountable for that authority, and how its keys were verified.
  • Shared Signals: which events can change this agent’s TRUST position, and who receives them.
  • Capability Inventory and Continuous Evidence: the record that the agent exists, and when its accountability chain was last verified.

Add what the diagram leaves open (named sponsor, model provenance, delegation depth) and you have the TRUST data elements of a MAR. Even a simple inventory with a named sponsor for every agent is a meaningful first step. I’ll work through the elements for CRED, PRIV, and BEHAVE as the series continues.

Where this is going

CRED is next, completing the Identity side. After that, I’ll write about PKI, which serves both TRUST and CRED, and about what post-quantum cryptography does to each. Then PRIV and BEHAVE on the Access side, with one important difference for agents: the behavioral anchor isn’t historical baseline, it’s declared purpose.

Thanks to Mike for a diagram that gave this discussion a foundation and gave the four dimensions a picture.

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