Aegis -ZK Compliance Guardrails

Let an AI agent spend your money under a policy it can prove it followed without ever revealing the policy, your spending history or your recipients on-chain.

Comment

Inspiration

AI agents are starting to get real financial and data autonomy -paying bills, managing subscriptions, executing trades. But "trust the agent's logs" isn't a security model: logs can be edited after the fact, and a compromised or misaligned agent can lie about what it checked. We wanted an agent's compliance to be provable, not just claimed - and provable without turning the user's entire financial life into public on-chain data.

What it does

Aegis lets a user register a private policy (spend cap, allowed categories, an allowlist of recipients) as a cryptographic commitment on-chain - the actual numbers and rules never appear on the ledger. Before the agent can execute any action, it must produce a zero-knowledge proof, inside a Compact smart contract, that the action:

  1. Is in an allowed category
  2. Targets an allowlisted recipient (Merkle membership)
  3. Keeps cumulative spend under the (still-hidden) cap

Only a passing proof produces a public, tamper-evident attestation receipt. A non-compliant action can't produce one — the circuit itself aborts. A nullifier stops the same invoice from being paid twice (replay protection). The owner can later selectively disclose one fact about one past action (e.g. "this payment was under $60") to an auditor without opening the policy or any other action, and can revoke the agent's authority instantly as a kill switch.

How we built it

  • contract/src/aegis.compact — 12 circuits (policy registration, recipient allowlisting, the core submitAction guardrail, revoke/reactivate, two selective-disclosure audit circuits, read-only getters), compiled with Compact toolchain 0.31.1.
  • 9 passing tests against the real compiled circuits via @midnight-ntwrk/compact-runtime — not mocked — covering every accept and every rejection path (bad category, non-allowlisted recipient, over-cap spend, replay, post-revocation) plus both selective-disclosure audits.
  • Two working backends behind one API: an in-process simulator, and a real deployment path (@midnight-ntwrk/midnight-js-*) against a local Midnight devnet (node + indexer + proof server) — a genuinely deployed contract producing genuine on-chain transactions, verified end-to-end: onboard → registerPolicy → addAllowedRecipient → a compliant action (attested) → each rejection reason → a selective-disclosure audit, all against the live chain.
  • A full React/TypeScript UI with 7 panels (onboarding, policy, recipients, actions, a live attestation feed contrasting public vs. hidden fields, an audit panel, a kill switch), including real Lace wallet connect via the DApp Connector API — the app never sees or stores the wallet's raw key, only a signature the user approved.

Challenges we ran into

The publicly installable @midnight-ntwrk/compact-js SDK is pinned to an older compact-runtime than the newest Compact compiler targets — a real version-skew gap in Midnight's own published packages, not a wiring bug on our end. We diagnosed this by reading the actual release notes rather than guessing, and fixed it by deliberately compiling against Compact toolchain 0.31.1 (the version release notes confirm still targets the current Mainnet ledger), instead of the newer 0.34.x line. That swap then surfaced three more real SDK-shape mismatches - a shifted createCircuitContext argument, duplicate WASM module instances failing identity checks, and a larger-than-documented PrivateStateProvider interface - each confirmed empirically against the actual installed packages before being patched.

Accomplishments that we're proud of

A genuinely deployed, genuinely working ZK guardrail contract on a real Midnight devnet not a mockup with every accept/reject path and both audit circuits verified against live on-chain execution, plus a real wallet-connect flow, all built and verified in a single hackathon weekend.

What we learned

How thin the gap can be between "the docs say this should work" and "this actually compiles and runs" in a fast-moving ecosystem the compiler, the SDK, and the runtime are all shipping independently, and the only way to trust any of it was to compile, deploy, and test against the real toolchain rather than reasoning from memory or documentation alone. We also learned the value of building two backends (an in-memory simulator and a real devnet path) side by side, so we always had a working demo even while chasing down real infrastructure bugs.

What's next for Aegis - ZK Compliance Guardrails

A second derived AgentPublicKey, distinct from the owner's policy-control key, so the owner can hand a scoped credential to the actual agent runtime instead of sharing the same secret used to change the policy or revoke it.

Built With

Share this project:

Updates

Submission history