Skip to main content
Developer Resources

Evaluate the platform.

Run the full proof lifecycle in under a minute.
Seal a policy, govern tool calls,
verify evidence offline.

Run the 60-second eval

Platform metrics verified against current codebase

Same trigger · two outcomes

What governance looks like.

Trigger

Agent receives prompt-injected instruction

Without AGA·Silent failure
  1. 1

    Executes unauthorized API call

  2. 2

    Writes partial log entry

  3. 3

    No governance · no proof · no detection

With AGA·Cryptographic proof
  1. 1

    Proxy intercepts tool call

  2. 2

    Policy violation: tool not in sealed allowlist

  3. 3

    Decision recorded: DENIED (enforcement wired per-deployment)

  4. 4

    Signed DENY receipt generated

  5. 5

    Receipt appended to continuity chain

  6. 6

    Evidence bundle verifies: PASS

Receipts are signed behind a key-isolated boundary: in the two-process deployment, the agent process never holds the signing keys.

Command Line

Install, seal, verify.

The CLI is the primary interface, with no infrastructure beyond the binary itself. The sequence below runs it end to end: initialize a chain, seal a policy, run the governance proxy, verify the evidence offline. The published packages let you run the demo and verify a bundle offline today.

Full AGA CLI lifecycle
# Generate keys and initialize chain
aga init --standalone

# Validate system health
aga doctor

# Seal a governance policy for an MCP agent
aga seal --file agent.bin --model-name research-agent \
  --tool-policy-file policy.json -o sealed-artifact.json

# Start the governance proxy
aga proxy --upstream localhost:3000 --artifact sealed-artifact.json

# Export and verify evidence offline
aga export -o evidence.json
aga verify --bundle evidence.json
Verify us without trusting us

The verifier is published. Check us with it.

The same Ed25519-SHA256-JCS construction the gateway signs with is published as a standalone command-line verifier on npm. It is our own package, so the point is not that we vouch for it: run it yourself, or run the VerifyBundle offline verifier in your browser. The format is specified so you can re-implement it. The package ships with SLSA build provenance; verify the attestation on /provenance.

$ npx -y @attested-intelligence/aga-verify@2.1.1 evidence-bundle.json
Open the live verifier Offline verifier (VerifyBundle) aga-verify on npm

What you get depends on the key. Without a pinned key the verifier confirms integrity only: that the bundle is internally consistent under its own key. Pin the gateway key to also prove who issued it and to rule out whole-bundle re-signing.

The demo gateway key is a published fixture, and a live deployment uses a persisted key (the server’s default key is ephemeral).

What’s Built

A working reference implementation.

384 automated tests in the reference implementation. Verdicts are identical across three toolchains (JavaScript, Go, Python) on all 57 classical cross-stack cases; the 28 post-quantum composite cases are specified and reference-verified across two language oracles. Offline verification re-derives the decision, with no stubs in the verification path.

CLI

The full AGA CLI spans 13 commands: init, seal, deploy, verify, export, audit, status, gate, rotate, policy, proxy, doctor, version. The published packages run the demo, offline verify, and export today; the rest ship with the platform, plus a SIEM/EDR export of the governance chain as JSONL.

Governance

Integration points wired per deployment: an HTTP reverse proxy, an Envoy ext_authz gRPC server, and a Kubernetes admission webhook (failurePolicy: Fail) that rejects unsealed pods.

Policy Profiles

12 pre-built profiles spanning SCADA, defense, AI agent, healthcare, financial services, and EU AI Act high-risk deployments. Custom profiles supported.

Crypto Stack

Ed25519 live; the ML-DSA-65 + Ed25519 hybrid composite cross-verified (FIPS 204). SHA-256 and BLAKE2b-256 hashing, Merkle inclusion proofs, and 57 + 28 cross-language conformance cases.

Evidence

Continuity chain with hash-linked signed receipts. Offline evidence bundles with Merkle inclusion proofs. HTML audit reports via aga audit --format html.

Health Check

aga doctor runs a 21-point diagnostic validating keys, policy state, chain integrity, proxy connectivity, and governance readiness. One command, full stack validation.

Illustrative aga doctor output
$ aga doctor
[PASS] Key pair exists (portal.key, portal.pub)
[PASS] Key algorithm: Ed25519
[PASS] Public key readable (32 bytes)
[PASS] Policy artifact exists
[PASS] Policy artifact signature valid
[PASS] Policy effective period active
[PASS] Agent identity hash present
[PASS] Governance mode: mandatory
[PASS] Chain store initialized
[PASS] Chain integrity: 0 broken links
[PASS] Receipt signature algorithm: Ed25519-SHA256-JCS
[PASS] Merkle tree depth: 4 (16 leaves)
[PASS] Proxy listener: localhost:8080
[PASS] Upstream reachable: localhost:3000
[PASS] ext_authz gRPC: disabled (standalone mode)
[PASS] Admission webhook: disabled (standalone mode)
[PASS] Evidence export: ready
[PASS] Offline verification: ready
[PASS] Key rotation policy: max-age=720h
[PASS] gateway self-attestation: binary hash verified
[PASS] Roughtime: configured (roughtime.cloudflare.com)

21/21 checks passed. System healthy.

# illustrative; run aga doctor for your deployment's real checks
Verify a sample evidence bundle in your browser →

How this compares.

Logging
Records events after execution
Mutable by design; entries can be altered or deleted without detection
Monitoring
Detects anomalies during execution
Reactive by nature; damage occurs before a response can be triggered
Guardrails
Shapes model behavior via training and prompts
Probabilistic control at the model layer; effective for typical inputs but bypassable by adversarial prompts
Cryptographic Governance
Seals a deny decision before execution and generates signed proof
Requires routing through the governance boundary
See the full capability comparison
Run a pilot

What a pilot looks like.

You evaluate it yourself first. If it holds up, a pilot is four phases over 90 days, and your security team, not us, decides whether the evidence survives.

  1. 1
    Day 0 · self-serve

    Evaluate it yourself

    Run the demo and verify a real evidence bundle offline before any call. No account, nothing to install beyond Node. This page is the eval.

  2. 2
    Week 1

    Sandbox and wiring

    We wire AGA at your MCP boundary and persist a gateway key in your own secret handling. The same gateway public key across restarts is the stable identity your team pins.

  3. 3
    Weeks 2 to 4, then monthly

    Security review

    Your security team verifies real bundles on machines you control: unpinned for integrity, pinned for provenance, then two negative controls, a tampered bundle and a wrong pin, that must FAIL. The questions a review asks are answered below.

  4. 4
    Day 30 gate → Day 90

    Decision and writeup

    A go/no-go at day 30. If it is go, steady state runs to day 90 and closes with a co-authored writeup you can hand to a security review. If the evidence does not survive your reviewers' scrutiny, that finding is what we owe you.

Start now · before any call

Run the demo

The standalone demo: 4 tool calls, 4 signed receipts, offline verification. The full proof lifecycle in under a minute.

Start here

Inspect the chain

Run aga status for live governance state and aga audit --format html for a report, then upload the evidence bundle to the browser verifier.

Open verifier

See the deployment modes

Three modes. Standalone: aga proxy, no infrastructure. Kubernetes: helm install with an admission webhook. Service mesh: an Envoy ext_authz gRPC sidecar.

View architecture

Read trust and scope

Understand exactly what an evidence bundle proves and what it does not. Written like a threat model.

View trust model
The design-partner offer

A pilot, scoped honestly.

We take on a small number of design partners: teams shipping agents into environments where someone else must be able to check the record. A pilot is 90 days, paid, and founder-operated. We wire AGA at your MCP boundary; your security team, and any third party you designate, verifies real evidence bundles with published tooling; you get a co-authored writeup you can hand to the next security review. If the evidence doesn't survive your reviewers' scrutiny, that finding is what we owe you.

Design partners come first. We work with a few teams closely rather than many at a distance, and in exchange for the close work and a reference we can name, you get the security-review writeup co-authored with us. Terms are set in the pilot agreement, not on this page.

Wondering what happens to your evidence if we disappear? The honest answer is: nothing.

Book a technical briefing
Security review, answered

The questions a review will ask.

Five answers from the pilot's security-review sheet, including the two that say what a verified bundle does not prove.

How are the agent's actions recorded?

Each governed tool call at the MCP boundary is recorded as an Ed25519-signed receipt: tool, decision, reason, an arguments hash, a timestamp, and a hash link to the receipt before it. Receipts are committed into a Merkle tree, bound by a signed checkpoint, and exported as a self-contained evidence bundle.

How are those records protected from tampering?

They are tamper-evident by construction. Editing any signed field, reordering receipts, or removing one already committed breaks a signature, the hash chain, or the Merkle commitment, and verification fails on the reviewer's machine. Exactly four envelope fields (bundle_id, schema_version, the envelope copy of policy_reference, offline_capable) sit outside that binding as unchecked metadata; the remaining envelope copies are cross-checked against the signed values, and the signed policy_reference inside every receipt is bound and must match.

Can a third party check this without access to your systems?

Yes. The bundle is the whole audit surface. A reviewer runs the published aga-verify against the file, offline, without contacting us. Pinning the gateway public key upgrades the verdict from integrity to provenance.

What does a verified bundle NOT prove?

It does not prove non-omission: it cannot show that every action the agent took was recorded. That boundary sits outside the bundle, in how the interception point is deployed, and it is reviewed explicitly in the pilot. We prove the record; enforcement is a separate, per-deployment concern.

Does AGA stop a misbehaving agent?

That is not the claim this evidence supports. A decision, PERMITTED or DENIED, is recorded in a signed receipt; what a deployment does with a DENIED decision is a per-deployment configuration choice. We prove the record, not the enforcement.

The full sheet ships in the pilot pack. For the whole trust boundary, read the Trust and Scope page.

Known Limitations

Three constraints worth naming.

  • 1.Network routing. Governance requires the governed agent to route through the AGA proxy or Envoy sidecar. Direct tool access outside the proxy is not governed.
  • 2.Identity binding. Self-signed X.509 identity binding via SPIFFE. No external PKI or certificate authority.
  • 3.Time anchoring. System clock is primary. Roughtime IETF protocol available for timestamp corroboration.

For the full trust model, see the Trust and Scope page.

Integrate

Integration options.

The integrations provide language and platform paths into the same governance boundary.

Python SDK

Beta
Type
Package
Install
pip install aga-governance
Open PyPI

MCP Server

Stable
Type
Server
Install
npm install @attested-intelligence/aga-mcp-server
Open npm

Public Demo Endpoint

Live
Type
Endpoint
Install
curl aga-mcp-gateway.attested-intelligence.workers.dev/bundle

(live: emits a canonical evidence bundle you can verify offline with aga-verify; also persisted and retrievable at /bundle/{merkle_root}. The only official gateway is this hyphenated host; do not pin keys from any other host.)

Open GET

Browser verifier

Live
Type
In-browser
Install
client-side evidence bundle verification, no server calls
Open /verify

Go binary

Request access
Type
CLI binary
Install
aga seal | proxy | verify | export (Linux, macOS, Windows · amd64 + arm64)
Open Request
Reference

Post-quantum architecture reference

ML-DSA-65 + Ed25519 hybrid composite (NIST FIPS 204), implemented and cross-verified; Ed25519 is the live default.

Next

Ready to run a pilot?

Book a technical briefing and we will walk the four phases against your MCP boundary. The diligence pack, with architecture documentation, NIST submissions, and integration assessment materials, comes on request.

Book a technical briefingStart the eval
View technologyTechnical paperPosition paper