Home › Product › Capabilities › Proof of Intent

Proof of Intent

IntentGate's evidence layer. It converts raw, ephemeral agent-tool interactions into an immutable, cryptographically verifiable record. Where the Tool Schema Sanitizer cleans what an agent reads on the way in and Runtime Limits govern what an agent does on the way out, Proof of Intent is the layer that proves what happened. Each interaction is packaged into a tamper-evident envelope that captures what the agent intended, which safety checks evaluated it, and, by hash, what actually executed.

Why raw logs are not evidence

Traditional stdout logs are unstructured and disconnected. They rarely capture the agent's turn history, the tool parameters, and the policy decision in a single verifiable state, so reconstructing what really happened means stitching fragments together after the fact. That leaves three gaps that matter the moment anyone asks a hard question:

Unstructured, disconnected logs

Text logs record lines, not decisions. They don't tie the agent's turn sequence, the exact tool parameters, and the ALLOW/DENY/MODIFIED policy outcome into one coherent record, so there is no single artifact that shows the full state of an interaction.

Non-deterministic liability

When something goes wrong, auditors and incident responders ask precise questions: did the user authorize this action, and did a policy engine actually check it? Scattered logs can't answer that deterministically. Without a bound record of intent and decision, liability is a matter of argument rather than proof.

Log-tampering risk

Plain text logs can be altered, deleted, or spoofed. A record that anyone with access can quietly edit is not evidence, it is a note. The value of an audit trail depends entirely on being able to show it has not been changed.

The mechanism: a hash-chained audit ledger

Proof of Intent addresses all three gaps with a single structure, a hash-chained ledger of proof envelopes. For each agent-tool interaction, IntentGate:

1. Captures the execution context. Session id and turn sequence, agent and user identity, the tool name and a hash of its parameters, and the policy decision, ALLOW, DENY, or MODIFIED.
2. Binds the result by hash. The exact bytes the tool returned are referenced as result_sha256, a SHA-256 digest, so the envelope proves what was returned without carrying the raw response or any PII.
3. Chains the envelope. Each envelope carries a hash computed as Hash_N = SHA-256(EventData + Hash_(N-1)), linking it to the previous turn's envelope.
4. Signs the bundle. The assembled bundle is signed with HMAC-SHA256 using the gateway's signing key, and records the key id, never the key itself.

Because every envelope links to the one before it, tampering with or deleting any past turn breaks the whole chain and invalidates it instantly. It behaves like a local, private ledger: the linkage is what makes alteration self-evident. Verification recomputes the HMAC signature and re-walks the prev-hash chain, so both the signature and the linkage are checkable offline, no call back to IntentGate required.

What a proof envelope carries

A proof envelope is metadata and signatures, not payload. It references the tool result by SHA-256 hash and binds the declared intent, the tool, and the policy decision, the parts that establish what was meant to happen and whether it was authorized. The raw response never enters the envelope.

For each turn in a session, an envelope records a small, fixed set of facts. There is a unique, time-ordered event id and a timestamp, so the record has a place in the sequence. There is the agent identity and the tool it tried to call, for example a billing copilot invoking a "create payee" action. There is the policy decision, ALLOW, DENY, or MODIFIED, together with the check that made it and a short human-readable reason, such as a create-then-pay chain being held for human review. There is a one-line summary of the declared intent. And there is the result, referenced only as a result_sha256 digest, a hash that proves what came back without ever carrying the raw response or any customer data.

Two fields turn those per-turn records into a chain. Each envelope carries a prev_hash that points at the previous turn's hash, so the entries link in order and any gap or edit is visible. And the whole bundle carries a signature, an HMAC-SHA256 computed over its contents, alongside a key_id that names the signing key without ever exposing it. Verification recomputes that signature and re-walks the prev-hash links, so both are checkable offline.

What Proof of Intent actually does

To keep the claims honest: the SHA-256 hash chain, its prev-hash linkage, the tamper-evidence that linkage provides, and offline verification are real and shippable, state them with confidence. The bundle is signed with HMAC-SHA256 using the gateway's signing key; it is not an ECDSA node key pair. Each entry carries a unique, time-ordered event id. The envelope references the tool result by result_sha256, so it holds a hash of the result and never the raw response or PII, but it is not empty of context: it binds the declared intent, the tool, and the policy decision, and those stay inside your customer boundary. What crosses the federation boundary is zero-payload, counts and hashes only. Enforcement is deterministic and sub-millisecond. On storage and streaming, the local hash-chained audit ledger and SIEM export to Splunk, Microsoft Sentinel, and S3 are real and shipping; an optional Kafka audit stream is on the roadmap, not a shipping dependency.

What it's worth

Proof of Intent buys three things. The first is audit-ready evidence: a signed, hash-chained record that maps directly onto the assurance obligations in the EU AI Act, SOC 2, ISO 27001 and ISO 42001, and HIPAA. The second is defensible liability: you can prove the gateway enforced every policy and reproduce the exact sequence of events, without exposing raw customer data, the answer to "did the user authorize this, and did a policy engine check it?" becomes a verifiable artifact rather than an argument. The third is operational fit: the evidence feeds your existing pipeline as signed, regulator-ready records that export into your SIEM and GRC tooling, so assurance rides on the systems you already run.

Defence in depth

Proof of Intent is the evidence layer, not the whole story. It proves what happened after the fact; it pairs with the controls that decide what should happen in the moment. The Tool Schema Sanitizer cleans the tool definitions the model reads before any call is proposed. Runtime Limits & Circuit Breakers bound how fast, how far, and how expensively an agent may act. Intent Enforcement refuses calls that fall outside the user's declared intent. Sanitizing what the model reads, authorizing what the agent intends, governing how much it may do, and proving what it did are separate, composable layers. See the Capabilities overview for how the controls compose end to end.

Frequently asked questions

How does the hash chain make the audit trail tamper-evident?

Each proof envelope carries a SHA-256 hash computed over its own event data plus the hash of the previous turn's envelope, Hash_N = SHA-256(EventData + Hash_(N-1)). Because every envelope links to the one before it, altering or deleting any past turn changes its hash and breaks every link that follows, so the whole chain fails verification instantly. It behaves like a local, private ledger: the record is append-only in effect, and tampering is self-evident.

Is the audit ledger signed, and with what?

Yes. The bundle is signed with HMAC-SHA256 using the gateway's signing key, and it records the key id, never the key itself. Verification recomputes the HMAC and re-checks the internal prev-hash chain, so the signature and the chain are both checkable offline, with no call back to IntentGate required.

Does the proof envelope contain raw customer data or PII?

No. The envelope references the tool result by its SHA-256 hash (result_sha256), never the raw response or PII. It binds the declared intent, the tool name, and the policy decision, which stay inside your customer boundary, while what crosses the federation boundary is zero-payload: counts and hashes only. You can prove exactly what happened without exposing the underlying data.

Proof of Intent is IntentGate's evidence layer. See also: Tool Schema Sanitizer, Runtime Limits & Circuit Breakers, Intent Enforcement, Capabilities.

See it in the live demo → Try the interactive scenarios on the demo page to watch decisions become signed, hash-chained evidence in real time.