Skip to content

Architecture

The mandate is a four-document structure — a signed intent, an evidence bundle, a proposal, and a zero-knowledge proof — that together prove an agent's proposal satisfies the constraints a principal declared.

Mandate architecture: principal → policy template → agent proposal → policy-engine evaluation → SP1 prover → guardrail verifier.

1 · Principal — signed intent

A human (or a policy author on their behalf) writes a policy template in a small, readable language: schemas for an intent map and an evidence map, plus a requires block of constraints. The template is compiled to portable bytecode and identified by a base58 SHA-256 hash, the template_id.

The principal then signs an intent: a template_id + the field values that fill the template's intent schema. That signature is the binding promise: "I am committing to a trade with these limits, against this template."

See policy-engine/docs/LANGUAGE.md for the template grammar.

2 · Agent — proposal

An agent proposes a concrete operation that should satisfy the intent — for example, the URL of a specific product to buy, or a transaction payload. The proposal carries no privileges by itself; it's just data.

Evidence is extracted from the proposal: the price, the seller country, the warranty length — whatever fields the policy template's evidence schema declares. Extraction is out-of-band (a separate API or scraper), and its only contract is to produce values that match the schema.

3 · Policy engine — evaluate

The policy-engine takes the compiled template, the intent map, and the evidence map, and checks: does the input conform to the schemas, and do the constraints in requires hold?

The engine doesn't check signatures or trust any of the data — that's the caller's job. It's a pure evaluator: schemas in, boolean-with-reason out. The same library backs both the local-development CLI and the in-zkVM evaluator that the prover runs.

4 · Prover — zero-knowledge proof

The agentic-guardrails prover runs the policy evaluation inside an SP1 zkVM and produces a succinct zero-knowledge proof that the evaluation succeeded for the provided intent + evidence + template. The proof binds to those exact inputs; nothing else can be substituted.

The compiled policy-engine evaluator is registered with the prover as an ELF (its hashed bytecode); each ELF gets an elf_id and a verifying key. Provers and verifiers reference policies by these ids, not by source code.

5 · Verifier — settle

The verifier accepts a finished proof, checks the zk verification using the corresponding verifying key, and exposes the result to downstream consumers (settlement systems, audit logs, on-chain contracts). A valid proof means: the proposal satisfies the principal's signed intent under the named policy template, and we have a portable artifact that attests to it.