How It Works
End-to-end flow of intent plan creation, CSRG verification, Merkle proof, and enforcement.
How It Works
The following diagram shows the end-to-end flow of how the Intent Assurance Plan processes and enforces execution plans:
1. SDK/Agent submits an execution plan
│
2. Backend validates policies and builds canonical plan
│
3. CSRG builds deterministic reasoning graph
│
4. Merkle tree computed over graph nodes
│
5. Ed25519 token signed with plan_hash
│
6. Token + step proofs returned to SDK
│
7. Each tool call verified:
a. JWT signature check
b. Backend step verification
c. CSRG Merkle proof verification
│
8. If verified → request forwarded to MCP server
If not → request blocked + audit loggedThe CSRG (Canonical Structured Reasoning Graph) ensures cryptographic non-repudiation - once a plan is committed, neither the agent nor any intermediary can execute unauthorized tool calls without detection.
Intent token signing
Intent tokens are signed with Ed25519 (EdDSA) when the backend has signing keys configured via IAP_TOKEN_ED25519_PRIVATE_KEY and IAP_TOKEN_ED25519_PUBLIC_KEY. The signed payload includes the plan, user, agent, and context identifiers; the plan_hash and merkle_root; the CSRG token and step proofs; and the resolved policy validation result (allowed and denied tools, matched policies, and the default enforcement action).
Verify a token's signature yourself with the current public signing key, published unauthenticated at:
GET /iap/public-keyThis returns the algorithm, whether Ed25519 signing is currently enabled, and the public key in both PEM and JWK form.
GET /iap/public-key/:kid is a different, unrelated endpoint that looks up CSRG/KMS-backed keys by key ID for a separate RS256 verification path. Use the plain GET /iap/public-key (no kid) for the Ed25519 intent-token key described here.
Legacy HS256 fallback
If IAP_TOKEN_ED25519_PRIVATE_KEY isn't configured, the backend signs intent tokens with the legacy shared-secret HS256 algorithm instead. On verification, the backend inspects the token's alg header: an EdDSA token is verified against the Ed25519 public key, and any other token is verified as HS256. This keeps older HS256 tokens valid during a migration window - there's no separate feature flag, the fallback is controlled purely by whether an Ed25519 signing key is present.