The problem
AI makes decisions you can't prove, can't audit, and can't hold accountable.
A compliance officer asks “why did the AI approve this?” The answer is “because the model said so.” That's not acceptable in regulated industries. Statistical AI guesses. It can't tell you why, and it can't prove it followed your rules.
What we do
We sit in front of the write and leave a receipt.
We sit between an AI agent and the action it's about to take, evaluate the action against mathematical governance rules, and produce a signed receipt of the decision. If it passes, it writes. If it fails, it's blocked. Either way, there's a receipt.
Input arrives
A user prompt, a tool call, or an agent action enters the gate. The ONLY Lang policy script is loaded for this context.
Gate evaluates
The gate runs the policy script against the input. The result is deterministic: ALLOW, DENY, or ESCALATE to a human. No probabilistic guessing.
Receipt issued
Every decision produces a signed receipt: the script, the input hash, the gate state, and the evidence. Verifiable by anyone — no trust required.
What we give you
A receipt you can verify yourself.
Signed receipts
Every AI decision that passes through our gate has a signed receipt — what was checked, what was decided, why. The receipt is verifiable by anyone, without trusting us.
Governance as math, not documents
The rules are executable code (ONLY Lang), not policy prose. The probes send real requests and record real responses. What you see is what actually happened.
Independent verification
The receipt inspector at /verify lets anyone paste a receipt and check its integrity. No account, no login, no trust. Just math.
Open and inspectable
The source is open. The receipts are verifiable. The probes are inspectable. The governance rules are executable code you can read.
What we won't claim
We won't say “trust us.”
Don't. Verify the receipt. Here's what we will and won't say.
We won't say
- “Your system is secure” — we can only say what the probes found.
- “This is a certified audit” — not until a third party audits the verifier.
- “89/89 passed means you're compliant” — it means our verifier produced expected outputs for our test cards.
- “Trust us” — don't. Verify the receipt.
We will say
- Every AI decision through our gate has a signed receipt.
- The receipt contains the evidence: what was checked, what was decided, why.
- The receipt is verifiable by anyone, without trusting us.
- The governance rules are executable math, not policy prose.
The honest gap: The verifier binary is our code. The Rust source is now published in native/, the build is reproducible, a differential test compares binary output against expected card results, and an audit package documents what is computed vs simulated — but the binary has not yet been independently audited. Until then, the receipt is evidence, not proof. Our commitment: the verifier should be audited by a third party, and we will publish the audit.
The harder problem — now enforced
Permission to act is not the same as continuing authority to act.
An agent can receive valid authority at T₀. By T₁, when it reaches the execution boundary, everything may have changed — the data, the policy, the delegation, the risk, the objective. Our enforcement gate now checks both: authorization is granted at T₀ and re-verified at T₁, with a signed receipt either way.
AUTHORIZATION → DELEGATION → CHANGING CONDITIONS → RUNTIME REASSESSMENT → EXECUTION → EVIDENCE
This is no longer a proposal. The gate is a running Rust service: verified identity (JWT/OIDC), signed versioned policies, human approvals, fail-closed partition handling, and signed revocation gossip between disconnected nodes — all tested against live instances, including a real CRM integration where 18 write tools execute only through the gate.
What the gate checks at T₀
- Who the agent is — a verified JWT sub claim (HS256, RS256, JWKS rotation, OIDC discovery), not a self-declared string.
- Whether it is revoked — checked against the shared authority store or signed gossip from peers.
- Which policy applies — Ed25519-signed, versioned, with rollback; tampered policies are rejected on load.
- Whether the justification qualifies — minimum-length enforcement plus an optional external semantic verifier hook.
- Whether the context is bound — a context hash binds the agent's full state to the decision, not just tool+params.
What the gate re-checks at T₁
- Token integrity — signature, expiry, exact action match, and params hash.
- Authority still valid — a second revocation check at execution; revoked between T₀ and T₁ means denied.
- Approvals received — policies can require N verified approvers before the token executes.
- Tool health — circuit breakers stop authorizing tools that keep failing downstream.
- Partition safety — if the revocation store is unreachable, the default is deny. Fail-open is an explicit dev opt-in, never silent.
The result: 250+ automated checks across the integration suites — govern/execute round-trips, JWT and JWKS rotation, approvals, policy signing, circuit breakers, sealed A2A transport, token delegation, quorum revocation, Merkle anti-entropy reconciliation, and partition behavior. Signed gossip propagates a revocation between disconnected nodes in ~60 ms; two instances sharing one store see it in ~4 ms (same-host lower bound, published as such). A forged or stale revocation is rejected, not applied.
What is shipped — and what is still open
Implemented and tested
- T₀ govern + T₁ execute re-check on every governed call
- Verified identity — JWT HS256/RS256, JWKS rotation, OIDC discovery
- Ed25519-signed policies with version history and rollback
- Human approval workflow — policies can require N verified approvers
- Fail-closed partition handling — storage outage denies, does not assume
- Signed revocation gossip — forged, stale, and replayed messages rejected
- Signed A2A envelopes with replay protection and two-party revocation checks
- Circuit breakers via caller-reported tool health
- Live CRM integration — 18 write tools governed end-to-end
- Sealed A2A transport — X25519 ECDH + AEAD payloads through a zero-knowledge relay
- Token delegation — monotonic authority decay; revoking the orchestrator kills the chain
- Quorum revocation at T₁ — execution verifies cluster quorum; isolated nodes fail closed; Merkle anti-entropy auto-reconciles divergence
- Sealed A2A v2 — ephemeral ratchet forward secrecy + hybrid post-quantum key combiner; v1 compatible (experimental crypto)
- T₀/T₁ quorum invariant — model-checked in TLA+ (exhaustive, N=3) and Alloy (bounded); residual partition boundary documented
- Prometheus metrics, structured logs, deep health, graceful shutdown
Still open
- Multi-leader Byzantine fault tolerance (BFT) — quorum is crash-tolerant read quorum (R + W > N); BFT consensus remains future work
- Independent third-party audit of the verifier binary
- Independent cryptographic review of sealed-v2 — the hybrid PQ construction is implemented and functionally tested; a formal design review has not been performed
- Quorum-write revocation — a revocation known only to partitioned-away nodes cannot be discovered by the remaining clean quorum (model-confirmed boundary)
- Code-level formal verification — the checked models are abstractions, not proofs about the Rust binary; bounds are small (N=3)
- Public-hosted deployment — artifacts and a posture check exist; still needs a real host, DNS, certificates and an OIDC issuer
- Semantic justification analysis inside the gate — currently delegated to an external verifier webhook
- Distributed circuit-breaker state — currently per-instance in memory
- Human review of whether a contract captures the intended objective
Passing our own tests is evidence, not certification. The gate is open source and the test suites ship with it — every claim above is a command you can run.
For developers
Free accounts to test your own systems.
Get a free developer account to run live probes against your own AI systems. No credit card. No sales call. Just a key and the documentation.
Run 30 live probes
Send real HTTP requests to your target system. Test authentication, injection, replay, scope, and more.
Get signed receipts
Every probe produces a PSR-001 receipt. Download, verify, and share with your team or auditor.
Integrate via API
Use the ONLY Lang SDK (Rust, Python, TypeScript) to embed the governance gate in your application.
How we engage
Discovery → Build → Deploy → Maintain.
Every engagement follows the same structure regardless of pathway. The client retains full control of the deployment, the keys, and the governance scripts. We provide tooling and expertise, not a black box.
Discovery
We review the client's regulatory constraints, existing infrastructure, and decision workflows. We identify which DGV test cards are relevant and which governance layers need custom configuration.
Output: deployment plan + verification report template
Build
We configure the governance stack, write the ONLY Lang scripts, and run the DGV test card suite against the configuration. The client reviews and approves every governance script before deployment.
No script goes live without client sign-off
Deploy
We deploy to the client's environment, configure the receipt store and audit feeds, and run a final verification pass. The client receives a signed verification report listing every test card result.
Output: signed verification report
Maintain
Quarterly governance reviews, DGV re-verification, and ONLY Lang script updates. The client retains full control of the deployment, the keys, and the governance scripts.
We provide tooling and expertise, not a black box
What you buy
Guard, Estate, Federation.
Three tiers. Pick one. Do not mix them on a single invoice. The spine is the offer sheet.
Guard
Live
Small business, few agents, their LLM keys
One SaaS tenant in front of the write. Draft-only is a real land. Send is YELLOW. Portal may accept.
Price this SKUEstate
Assessment-only
One regulated organisation, many humans
Protect-first wrap of every AI seat. A human binds the SOW. Portal cannot CLOSED_WON.
Price this SKUFederation
Assessment-only
Two named legal entities whose agents must talk
Two swarms, one handshake, two invoices. Workshop, never a cold PDF.
Price this SKUFor the board pack
Competitive field, procurement keys, and the claims we will not print
Public, Chained, Provable — DGV Goes Live
A real Hetzner host, real DNS and OIDC, the T0/T1 revocation and delegation-cascade proofs re-run externally, plus hash-chained offline-verifiable receipts and SLSA provenance
The previous update's honest non-claim — 'nothing is publicly deployed' — no longer holds. dgv-gate now runs on a real host behind real TLS, DNS, and a real Google OIDC issuer. The...
PrimeSwarm vs Google Gemini Enterprise Agent Platform
Google's own docs admit its flagship governance layer uses an LLM as judge, and can make mistakes — plus the documented integration point where a deterministic layer belongs instead
Google's shipped, flagship governance feature — Semantic Governance Policies — reads a proposed action and has an LLM judge it in natural language, with Google's own docs stating p...
The Gate Is a Running Service Now — DGV v0.4.0
Verified identity, signed policies, fail-closed partitions, and signed revocation gossip — measured, not asserted
dgv-gate is now a live enforcement service: T₀/T₁ authority re-checks, JWT/OIDC identity, Ed25519-signed versioned policies, verified human approvals, fail-closed partition handlin...
Sealed, Delegated, Deployable — DGV After v0.4.0
Encrypted agent-to-agent transport, tokens that can only narrow, and a deployment posture check that passed on real Postgres + RS256
dgv-sealed-v1 encrypts A2A payloads end-to-end through a zero-knowledge relay (X25519 ECDH + AEAD, payload hash binding the authorized ciphertext). dgv-delegate-v1 lets a token's g...