Identity & Security
Mandrel mandates a Compound Identity model to eliminate the risk of agents performing unauthorized actions.
This page describes the intended identity architecture. Several parts are specified and not yet built, and the table below says which. It is here rather than in a footnote because a security architecture that reads as though it is finished is worse than one that is honestly incomplete — an operator planning against this page needs to know what the enforcement engine actually checks today.
| Control | Status |
|---|---|
| Machine identity presented per request | Implemented, but self-asserted — the value is read from the request body, not from a verified certificate |
| Ingress allow-list matching | Implemented, segment-aligned |
| mTLS transport | Not implemented. Until it is, the machine badge is a claim rather than an identity |
| Nested JWT signature verification | Not implemented. Required scopes are matched against the token string |
| RFC 8693 actor-chain walk | Not implemented |
| DPoP (RFC 9449) | Not implemented. enforce-dpop is parsed and defaults to true |
| Step-up / HITL PoI verification | Implemented. Cryptographic Proof-of-Intent (PoI) Envelope verified with RFC 7800 ephemeral key binding, canonical JCS parameter hashing, and SUPERCEDE modification lineage |
| CAE revocation (RFC 8936) | Not implemented |
| Realized Spec signature | Specified and implemented in the SDK; not yet verified at spec load by the Collet |
The “Double Badge” Model
Every Agent-to-Agent (A2A) request must present two distinct context badges:
- Machine Context (SPIFFE): Verifies the workload identity via mTLS.
- Human Context (Nested JWT): Verifies the user intent and authorization chain.
These are evaluated by The Collet (Sidecar) using Open Policy Agent (OPA) to ensure the request satisfies the Mandrel Spec.
Protocol Alignments
Chain of Custody (RFC 8693)
As requests traverse the mesh, The Collet prevents “Identity Wash.” It exchanges the user’s token for a delegated token containing the act (Actor) claim, ensuring a full audit trail: “User A, delegated through Orchestrator B, executed by Specialist C.”
Sender-Constrained Tokens (DPoP)
To prevent replay attacks, the architecture mandates RFC 9449 (DPoP). Tokens are mathematically bound to the agent’s SPIFFE private key.
Step-Up Authentication (HITL) and Proof-of-Intent (PoI)
High-risk actions defined in enforcement-matrices utilize the Cryptographic Proof-of-Intent (PoI) framework (draft-williams-oauth-poi-core and draft-williams-oauth-poi-chained-state), aligning with RFC 9470 OAuth 2.0 Step-Up Authentication and RFC 7800 Proof-of-Possession semantics.
When a threshold or category trips action challenge or challenge-always, The Collet mints a signed Intent Challenge Object (ICO, application/poi+jwt;kind=chal) carrying:
- Tight temporal bounds (
[nbf, exp]). - Canonical parameter digest (
SHA-256(RFC 8785 JCS(raw_params))). - Ground-truth
display_facts(What You See Is What You Sign).
The client Signing Vault satisfies the challenge using an Ephemeral Intent Key (EIK) certified by the enterprise IdP via an RFC 7800 Key Certification Token (KCT). For Tier 1 actions (urn:ietf:params:oauth:poi:tier:session-pop), single-click approval generates a JWS assertion committing to the challenge hash without full IdP redirects. For Tier 2 and Tier 3 actions, platform biometric (WebAuthn UV) or hardware roaming authenticators (WebAuthn HW) are required.
When an operator modifies proposed parameters, the assertion executes a SUPERCEDE transition (H0 -> H1). The Collet verifies the hash chain and applies the verified human parameters directly to the downstream tool call, preventing agent hallucination on retry. Upon verification, The Collet countersigns an immutable audit receipt (CIR, application/poi+jwt;kind=rcpt). Legacy string attestations ("APPROVED") are strictly rejected.
Real-Time Revocation (CAE)
The mesh subscribes to Continuous Access Evaluation (RFC 8936). If a revocation event is issued, The Collet instantly terminates all active tool access and gRPC streams.
Signing and verification
How a Realized Spec is signed and checked — placement, coverage, the claim set, and the rule that the algorithm comes from the resolved key rather than the token — is specified in the metrology contract.