« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 08 — Agent & Workload Identity: NHI, OAuth 2.1, Token Exchange, SPIFFE, mTLS

Answers these JD lines: "Architect and own the agent identity and workload identity model for the platform, including non-human identity (NHI) management, agent identity lifecycle, blended user-plus-agent identity for delegated actions, and the identity propagation chain across multi-agent flows" · "OAuth 2.1 and OIDC flows for agent-to-tool and agent-to-API interactions, just-in-time credential issuance, short-lived token exchange, mTLS for agent-to-agent communication, and integration with the bank's enterprise IAM (Microsoft Entra ID, PAM, secrets management)".

Why this phase exists

This is the hardest unsolved problem in the JD, and the one where the bank's risk actually concentrates.

Human identity is solved. Service identity is solved. Agent identity is neither, because an agent has properties no existing model handles:

it acts on behalf of a user, so its authority is derived and must be bounded by the user's;
it acts across multiple hops, so authority must propagate and narrow at each one;
it discovers tools dynamically, so its permissions cannot be enumerated at design time;
it may delegate to other agents, possibly across organizational boundaries;
it is numerous — a bank will have hundreds of them, and non-human identities already outnumber human ones by a large multiple in most enterprises.

Static service accounts collapse under every one of those. A shared, long-lived credential with the union of every permission any agent might need is the default outcome, and it is exactly the finding an examiner writes up.

The mechanisms that survive contact with a real agentic flow are the ones this phase builds: short-lived, audience-scoped, sender-constrained credentials, minted just in time, carrying an explicit delegation chain.

Concept map

NHI (non-human identity): what it is, why the population explodes with agents, and the lifecycle — register → approve → issue → rotate → suspend → retire — with an owner.
Workload identity: identity derived from verified platform attributes (which cluster, namespace, service account) rather than from a secret. SPIFFE IDs and SVIDs (X.509 and JWT), trust domains, and SPIRE's attestation model.
OAuth 2.1: what consolidated — PKCE for all clients, implicit and password grants removed, exact redirect matching, refresh-token rotation or sender-constraint.
OIDC: the ID token (about the user, for the client) versus the access token (for the API) — the distinction people conflate.
Claims that matter: iss, aud, exp/nbf, sub, scope, act (the actor chain), cnf (proof-of-possession), jti. Audience validation as the confused-deputy defence.
RFC 8693 token exchange: trading a token for one with a narrower audience and scope while recording delegation in act. This is the backbone of multi-hop agent identity, and it is what makes Phase 03's delegation chain unforgeable.
Delegation vs impersonation: the chain is visible, or it is erased. Regulated environments want delegation.
Blended user + agent identity: the composite principal, and why both must appear in the policy decision and the audit record.
JIT credentials: minted at the moment of use, audience-scoped, seconds-to-minutes lifetime, never stored. Secret-less architecture as the goal.
Sender-constrained tokens: mTLS-bound (RFC 8705) and DPoP — why stealing the bearer string is not enough.
Enterprise integration: Microsoft Entra ID (managed identity, workload identity federation, on-behalf-of), PAM for privileged paths, and secrets management for what remains.

The lab

Lab	You build	Proves you understand
01 — The Identity Fabric	HMAC-signed JWT mint/verify with full claim validation including audience and clock skew; an OAuth 2.1 authorization-code flow with PKCE and a client-credentials flow; an RFC 8693 token-exchange endpoint that narrows audience and scope and appends to the `act` chain; a SPIFFE-style SVID issuer with trust domains and attestation; mTLS binding via a `cnf` claim so a stolen token is useless; a JIT credential broker with second-scale lifetimes; and an agent-identity lifecycle registry	that agent identity is derived, narrowed, chained and short-lived — and that every one of those four words is a control an examiner will ask you to demonstrate

Test contract: a token whose aud names another service is rejected; each exchange narrows scope and never widens it; the act chain is append-only and depth-bounded; a token without its bound key fails at the resource server; an expired SVID fails mTLS; a suspended agent's next credential request fails; and replay of a jti is refused. 104 tests, all green.

Deliverables checklist

Lab 01 green under LAB_MODULE=solution pytest and under your own lab.py.
You can walk a user token through three hops and show what changes at each.
You can explain delegation vs impersonation and why a bank wants the former.
You can list the claims a resource server must validate, and the attack each prevents.
You can explain the confused deputy in an agent platform, concretely.
You can describe SPIFFE/SPIRE attestation and what "secret-less" actually means.
You can explain sender-constrained tokens and when they are worth the complexity.
You can design the agent identity lifecycle, including suspension and revocation latency.

Key takeaways

Static service accounts do not survive agents. Every property of an agent breaks them.
Narrow at every hop. An exchange that widens scope is a bug; one that drops the chain is a finding.
The chain is derived from a verified credential, never asserted in a request body.
Both principals appear — the agent and the user — in the decision and in the record.
Short-lived beats rotated. A credential that lives for seconds does not need a rotation process.
Sender-constraint is what makes theft insufficient, and it is the difference between a bearer token and a bound one.