For security, platform and compliance teams running AI agents

Prove what your agents did not send.

Your coding and support agents read source, secrets and customer data. When an auditor, a customer or an incident asks "did any of this leave?", today the only answer is the agent vendor's own log. PNX (Proof of Non-Exfiltration) turns every agent run into a signed proof that none of your protected assets appeared in its outbound traffic, which anyone can verify offline without trusting you, the vendor or Crovia.

"During this run, none of these protected assets appeared in the agent's outbound traffic." That is a statement your auditor can check alone.

How it works

Same construction as TACET, our production transparency log: salted fingerprints, a sparse Merkle map, signed sheets, offline verifiers.

1 · Witness

Everything the agent sends is fingerprinted

A witness sits where outbound bytes are visible: Causari's local proxy (re proxy --pnx), your LLM gateway logs, or a CI step. Request bodies are cut into k-grams, hashed with a per-run salt and committed to a sparse Merkle map. The witness signs the run sheet, and an optional reach record lists every destination the run tried to reach under your allowlist.

2 · Prove

Per asset: absent, or exposed

For each protected asset (API keys, customer files, source directories) the prover attaches a non-inclusion path against the run root. If an asset did appear, the same object becomes signed evidence of the exposure. Any shared substring of 47 bytes or more is always detected, including inside JSON request bodies.

3 · Verify

Offline, by anyone, with open code

The auditor gets the proof, a ~kilobyte Crovia Seal, and optionally the assets. Three independent verifiers (Python, JavaScript in the browser, Rust) agree byte for byte on public conformance vectors. The proof contains no traffic bytes and nothing about the assets except their SHA-256.

Verify a real proof, here, now

These are the public PNX conformance proofs from the specification, verified in your browser by the same open-source code as /registry/seal/verify/. Nothing is sent to any server: open the network tab and check.

Why teams need this now

Audit

Evidence, not screenshots

SOC 2, ISO/IEC 42001 and customer security questionnaires now ask how AI agents are controlled. A per-run proof is an artefact you can attach to the control, and it holds up without asking anyone to trust your logs.

Regulation

DORA, GDPR, EU AI Act

Financial entities under DORA and every controller under GDPR Art. 33 must be able to show what happened, and what did not, around an ICT incident. PNX gives you a dated, signed statement for each agent run.

Sales

For agent platforms

If you sell an agent to enterprises, ship proofs of non-exfiltration as a feature. Your customers verify them without trusting you. We work with platforms that want to embed the witness.

The Agent Evidence Pilot

Four weeks, fixed scope, fixed price. For one team and one fleet of agents.

Week 1

Scope and wiring

  • Choose agents and runs: Claude Code, Codex, Cursor, CI review bots, your own
  • Define protected assets and the egress allowlist
  • Install the witness at your gateway, proxy or CI. Keys stay with you
Weeks 2–3

Live witnessing

  • A PNX proof for every witnessed run
  • Reach records: blocked and unexpected destinations, signed
  • Weekly review of exposures and gaps, if any
Week 4

Evidence pack

  • All proofs, verifiable offline
  • A report mapping the evidence to your controls (SOC 2, ISO/IEC 42001, DORA)
  • A walkthrough with your auditor or security reviewer
  • A plan for production

Try it today, free and open source

Apache-2.0 code, CC0 specification, Internet-Draft draft-crovia-tacet. No account, no Crovia server in the loop.

GitHub Actions

croviatrust/pnx-action

- uses: croviatrust/pnx-action@v1 env: STRIPE_KEY: ${{ secrets.STRIPE_KEY }} with: egress: logs/gateway.jsonl assets: data/customers.csv asset-env: STRIPE_KEY witness-seed: ${{ secrets.PNX_WITNESS_SEED }}
Developer machine

Causari as the local witness

re proxy --pnx --pnx-policy egress-policy.json re pnx prove --asset api_key=.env --assets-dir src/secret/ re pnx verify .causari/pnx/<run>/proof.json \ --asset api_key=.env --assets-dir src/secret/
LLM gateway

LiteLLM (SDK or proxy)

pip install "crovia-tacet[litellm]" # SDK litellm.callbacks = [PNXEgressLogger("pnx/egress.jsonl")] # proxy config.yaml litellm_settings: callbacks: tacet.integrations.litellm.pnx_egress_logger
Any pipeline

tacet-pnx (Python)

pip install crovia-tacet tacet-pnx keygen tacet-pnx witness ... # sign the run sheet tacet-pnx prove ... # per-asset proof tacet-pnx verify pnx.proof.json --asset ...

What a PNX proof does not claim

The limits are part of the specification (PNX §7). We state them before you ask.

Bytes the witness did not see. Traffic that bypassed the witness, TLS it could not read and side channels are outside the proof. The proof is only as complete as the boundary that forces traffic through the witness, and it says which capture was used.
Transformations it does not normalise. Paraphrase, translation, summaries, base64, URL-encoding and UTF-16 are outside the proof. Raw bytes and JSON string values are covered.
Very short assets. Assets under 32 bytes cannot be covered. Assets that are short or only partly covered are reported as undetectable or absent-partial and are never counted as clean.
A single witness is one statement. Countersigning by several independent witnesses (Countersign) removes that single point of trust.

Your auditor will ask. Have the proof ready.

Tell us which agents you run and what must never leave. We reply within one business day with a pilot scope.