Why sign a permit
IntentChain does not reduce approval to a boolean allow decision. It issues a signed permit that binds the approved action to a concrete request, a concrete agent identity, and a narrow execution window.
That is the core design choice. The system has to answer a stronger question than "was policy checked?" It has to prove the request about to be forwarded is still the request policy approved, under the same rules, and that the approval cannot be replayed later.
What the signed permit binds
The permit is compact, but each segment carries security meaning. The header identifies the signing key, the payload captures the approval context, and the signature gives the gateway something it can verify before touching credentials or forwarding traffic.
{
"alg": "EdDSA",
"typ": "JWT",
"kid": "tenant_001_v1"
}{
"jti": "a1b2c3d4",
"iss": "intentchain-cp",
"iat": 1712429400,
"exp": 1712429460,
"agent_id": "wire-transfer-agent",
"canonical_action": "money.payment",
"target_system": "bank-prod",
"request_hash": "sha256:e4b2d1...",
"policy_version": 14,
"policy_inputs": {
"amount": 5000,
"currency": "USD",
"from": "acct_8832",
"to": "acct_4421"
}
}How gateway verification adds security
The gateway does not treat the permit as a generic bearer token. It verifies the signature, checks expiry, confirms the permit has not already been consumed, and recomputes the request hash against the exact payload about to be forwarded.
- Signature: proves the control plane actually issued the permit for this tenant.
- Expiry: keeps the execution window short enough that approvals cannot sit around and be reused later.
- Request hash: blocks payload drift between policy approval and forward-time execution.
- Single-use permit ID: rejects replay even when the request itself is identical.
- Policy version: ties the mutation to the exact ruleset that approved it.
Only after those checks pass does IntentChain retrieve downstream credentials and forward the request. Verification happens before the execution path touches a protected secret or target endpoint.
Why single-use closes replay gaps
High-risk agent actions do not fail only through bad decisions. They also fail through repetition: retries, loops, duplicate sends, and race conditions. A permit that can be replayed is just a short-lived access token. A permit that is consumed on first use is an execution guard.
That is the point of the permit design. Each field exists to close a common gap between approval and execution. The permit is not descriptive metadata layered onto the system after the fact. It is the cryptographic mechanism that makes the execution rail deterministic and materially safer.