We host your database (and optionally your app) behind a transparency proxy. Every database access — app and admin — is cryptographically logged into a per-user Merkle chain, labeled by identity, and visible to the affected user the moment it happens. You get a security property — data access accountability — as managed infrastructure, not as something you bolt on later or trust a vendor to enforce.
A tamper-evident log endpoint — events you POST get hash-chained, the head gets anchored every 30 minutes to GitHub (signed commits) and OpenTimestamps (Bitcoin), and a public WASM verifier runs in your customer's browser. Datadog, Logtail, CloudWatch, and Loki don't ship cryptographic tamper-evidence as a primitive — the operator (or any admin with retention permissions) can mutate the backend without leaving evidence. We're the only one in that market where the customer can prove to *their* customers and auditors what was logged and that it hasn't been rewritten. Sharpest fit: AI agents publishing their own tool-use logs, because the agent is a separate actor the company *wants* publicly accountable. Honest limit: we make no claim about events you chose not to log — we make a cryptographic claim about what you did.
You keep both. Datadog is durable, queryable, and not externally verifiable — Datadog can rewrite Datadog, and so can any admin in your org with retention permissions. Mirror the audit-relevant subset (the events your customers, regulators, or board would care about) to the self-attested endpoint. Your customers and auditors get a verifier they can run without trusting either of us. The chain head is anchored to GitHub + Bitcoin, so even a coordinated rewrite by both of us would have to forge the anchors in external systems we don't control. Datadog stays your operational log. Self-attested becomes your auditable log.
Different threat model, different audience, different ingest path — same chain format and verifier. Self-attested: REST/MCP endpoint, you POST what you want logged, fits AI-native teams whose threat model is "we want our log to be cryptographically auditable." Structural: a transparency proxy in front of your database, every query captured architecturally, fits regulated-vertical CTOs whose threat model is "the admin is the adversary" — opting out requires opting out of the database. The structural product is the upsell *only* when your threat model changes, not as a graduation path. Most AI-native teams stop at self-attested forever.
No. pgaudit is a Postgres extension configured by the same admin it is supposed to audit: they can silence it, change its schema, filter rows before the log is written, or rotate the log file out of existence. It is opt-in and bypassable by construction. The Unincorporated Protocol is opt-out: every query flows through the proxy on its way to the database, the chain entry is written before the response is returned, and the user has a cryptographic proof of what the chain contains. An admin who modifies a past entry breaks the hash linkage of every entry after it, and the break is visible to the user running the client-side verifier. pgaudit is a compliance checkbox; this is a structural property.
Those products log for the company that is being audited. When Meta was fined €1.2B in May 2023 for GDPR violations, the audit evidence Meta produced was a query against its own internal logs — reviewed by auditors under NDA, never shown to the affected users. Imperva, Varonis, Cyral, and CloudTrail all sit on the same side of the trust boundary: they are instruments for the CISO, not for the data subject. We log for the affected user. The chain is verifiable in their browser via WASM — the server (ours or yours) cannot fake a passing result. That is a different product category, not a better version of the same product.
They can copy the technology — Merkle chains, Rust proxies, client-side WASM — in a quarter. What they cannot copy without revolting their existing customers is the trust model. Every one of those companies sells to the compliance team and logs for the compliance team; their entire value proposition is "the company controls the audit narrative." Flipping to "the user verifies it, not the company" would require them to tell their existing customers that the audit log is no longer the company's property. That is a business-model reset, not a feature-parity sprint. We were built around user verification from day one, which is why copying us is structurally harder than it looks.
No. The proxy runs as a separate process — a standalone Rust binary you talk to over the Postgres / MongoDB / S3 wire protocol, exactly like you talk to a real database. You do not link against it. Your application code stays on whatever license you already use. AGPLv3 only applies to modifications of the proxy itself and only if you run those modifications as a network service. If you self-host from the open-source repo and do not modify the proxy, nothing in AGPLv3 reaches your application code. If you want a signed commercial-use letter for your legal team, ask us.
Yes — and arguably it matters more for AI than for humans. The proxy intercepts wire-protocol traffic regardless of who issued the query, so an LLM with tool-use database access (LangChain, CrewAI, AutoGen, LlamaIndex, or anything you rolled yourself) shows up in the chain the same way a DBA does. Your application labels the connecting credential — `agent:customer-service-bot` instead of `admin@company.com` — and the affected user sees that label in their transparency dashboard. The urgency is structurally higher for agents than for humans: "we trust our employees" survives a polite conversation, "we trust our LLM" does not. We do not claim to evaluate whether the agent should have made the query — that is interpretability and model evaluation, which is a different problem handled by a different class of tool. We claim that when the agent does make the query, your customer can verify it happened, and your audit log can finally tell agent traffic apart from human traffic. Works identically whether you self-host the open-source server or use managed hosting here.
The proxy exposes an MCP (Model Context Protocol) server endpoint. Any MCP host — Claude Desktop, OpenAI Agents SDK, Block goose, your own — can register the proxy as a tool source, and every tool invocation that hits the database becomes a chain entry with full tool-call metadata (tool_call_id, model name, framework). Your end users see "agent:customer-service-bot (claude-3-7-sonnet) via MCP" in their transparency dashboard, not an anonymous admin read. We track the MCP auth working group at the Linux Foundation's Agentic AI Foundation, and our goal is to be the open-source reference implementation of MCP authentication and audit. A2A support is on the roadmap pending the v1.0 spec stabilization.
Article 12 of the EU AI Act (Regulation 2024/1689) requires high-risk AI systems to have automatic, tamper-evident event logging for their entire operational lifetime. Full application is August 2, 2026. Our per-user Merkle chain provides all three structural properties — automatic (the proxy intercepts wire-protocol traffic, opt-out is not possible), tamper-evident (Merkle chains break on the first modified byte), and user-verifiable (WASM verification runs on the data subject's machine, the server cannot fake a passing result). We are not a certifying body and we do not issue AI Act conformity assessments. We are the deployable infrastructure that satisfies the logging requirement structurally instead of via a compliance attestation about an ELK stack nobody can verify. See the /ai-act page for the full Article 12 breakdown.
The chain always captures: session_id, credential label (e.g. agent:triage-bot), query fingerprint, affected users, timestamp. When the agent framework exposes it — most do — we also capture tool_call_id, model name (e.g. claude-3-7-sonnet), and a SHA-256 hash of the prompt. We hash prompts rather than storing them so that your proprietary prompts never leak into the transparency chain, while auditors can still verify that a specific tool call was driven by a specific prompt. If your agent framework does not expose these fields, the chain still records the wire-protocol access with the credential label — you do not lose coverage, you lose enrichment.
No. We make the evidence; your auditor still runs the audit. What you get is a tamper-evident, user-verifiable record of every database access — which is the artifact most data-access-audit controls (GDPR Article 32, HIPAA §164.312, SOC 2 CC7.2) ask you to produce. Your auditor still reviews the evidence, signs off on your overall control environment, and issues the report. We are not a certifying body and we do not pretend to be one. What we change is that the row on the questionnaire stops being a policy attestation and starts being a cryptographic artifact your auditor — and your customer — can verify themselves.
Every managed deployment gets the same 5-VM transparency topology in a dedicated per-deployment VPC in our GCP project: 1 proxy VM (running the Rust proxy, chain-engine, NATS, and dashboard), N database replica VMs (3 for the standard self-serve shape, 5 or 7 for custom shapes) each with a chain-MinIO sidecar for quorum-replicated chain storage, and 1 independent observer VM that subscribes to the database's own replication stream (Postgres WAL, Mongo oplog, MinIO notifications) and maintains its own chain for cross-verification. The proxy VM has a public IP; the database and observer VMs do not. Replica count and VM size are configured per deployment — same trust design across every shape. Pricing for the broader managed service is being calibrated against the design-partner cohort; concrete tiers will publish on /pricing once the program is full.
Only if you check the box. "Host my app" is a checkbox at onboarding, not a separate tier. If you check it, you hand us a Dockerfile or link a git repo and we build with Cloud Build, push to Artifact Registry, deploy on Cloud Run in the same region as your VPC, wire the Cloud Run egress through a VPC connector so it reaches the proxy on private IPs, and optionally map a custom domain with Google-managed TLS. If you leave it unchecked, you keep running your app wherever you already deploy it (Vercel, Fly, your own box) and dial the proxy's public IP for whichever primitives you use. Same price either way — the infrastructure cost is dominated by the 5-VM core, not the optional Cloud Run revision.
No. Your ORM, drivers, and migrations work unchanged because the proxy speaks native Postgres, MongoDB, and S3 protocols. If you host your app with us too, we inject the connection string as an environment variable when we deploy your container — you change nothing. If you host your app elsewhere, you change one connection string per primitive to point at the proxy's public IP.
Yes, when you also check "host my app". We use Cloud Run's built-in custom domain mapping, which provisions a Google-managed TLS certificate automatically. You add one CNAME record at your registrar to point at the target we give you, and we handle the rest. If you keep hosting your app yourself, custom domain stays on your side — the proxy only exposes the database wire protocols, not HTTPS for your app.
Ours. We host every deployment in our GCP project with per-customer isolation (one VPC per deployment). We do this on purpose: the topology requires us to hold root over the replica and observer VMs to enforce no-SSH, no-public-IP, and deterministic entropy-seeded role assignment. If you owned the GCP project, you would also own root access to the VMs, which would defeat the adversarial-admin threat model the 5-VM topology exists to defend against. Bring-your-own-cloud may come later but is not part of the current offering.
Postgres, MongoDB, and S3-compatible object storage (via MinIO). You pick any subset at onboarding — only Postgres, only Mongo, all three, or any combination. NATS runs internally on the proxy VM as part of the chain event pipeline, but it's not a customer-facing primitive. NATS is always on because turning it off would break the asynchronous chain pipeline and either block your queries or drop chain entries — both of which would be security holes.
Two layered defenses catch it. First: the per-user and per-deployment chains are quorum-replicated across the chain-MinIO sidecars on the database replicas. chain-engine waits for ⌊N/2⌋+1 acks before committing a write — 2-of-3 at 3 replicas, 3-of-5 or 4-of-7 for custom shapes — so a compromised proxy cannot silently rewrite chain history without contradicting the committed quorum. Second, and more importantly: the Observer VM is an independent subscriber. It reads the database's own replication stream (Postgres WAL, Mongo oplog, MinIO bucket notifications) and maintains its own chain from what the database actually applied. Then it compares its chain against the proxy's chain. A proxy that lies about what it did — claiming an event it never forwarded, or forwarding an event it never logged — shows up as a mismatch and fires an alert before the admin session ends. v1 ships with a single observer VM, which is a meaningful hardening over proxy-only designs but is not yet a multi-observer Byzantine quorum. See ROADMAP.md v1.1 and v2 for the multi-observer upgrade path and the honest limit on operator-customer collusion.
We log everything that reaches the database; we cannot prevent everything that reaches a screen. Camera, not the locked door. The full per-tier matrix — what each deployment tier (self-hosted, managed v1, managed v2) catches with a chain entry, what it only surfaces, and which scenarios remain genuine gaps — lives at /docs/threat-model. Every row is honest: we list the gaps we don't cover alongside the ones we do, because a CISO who finds a hidden gap after they sign is a customer we never get to keep.
Not silently. Every deployment that opts into app hosting boots in Dev mode, where your Cloud Run app can reach any public destination (same as a vanilla Cloud Run deploy) and every outbound destination is recorded on your deployment's transparency chain. When you promote to Prod mode, Envoy enforces a per-deployment allowlist on the TLS destination hostname, Cloud DNS returns NXDOMAIN for unlisted names, and the proxy VM itself is restricted to TCP/443 outbound. We do not promise mathematical containment — Rice's theorem forbids it, and anyone claiming otherwise is lying. What we promise is that every destination the app reached is on a cryptographic record your end users can read, in both Dev and Prod modes. Full threat model, four-layer defense, and the compliance-framework mapping are in docs/outbound-containment.md.
Because declaring every third-party service your app needs before you've deployed it is painful, and getting it wrong means your first day is spent debugging 403s from Stripe. Dev mode gives you the same first experience as a vanilla Cloud Run deployment — your app can reach anything — while silently recording every outbound destination on your deployment's chain. When you're ready for production, click Promote to Prod in the console: we pre-populated your allowlist from the destinations your app actually reached in Dev, you uncheck anything that was a debug call, acknowledge the monitoring policy, and promote. Dev mode also blocks custom-domain mapping (your custom domain only activates after promotion) and shows a prominent banner so nobody accidentally routes real traffic to a Dev deployment. Do not send real user data to a Dev-mode deployment — it is a discovery posture, not a production one.
In Dev mode, just use them normally — your app talks to Stripe, SendGrid, or OpenAI the way it always has, and we record every destination it reaches. When you click Promote to Prod, the pre-populated allowlist will already include every service your app actually hit. If there's a service your app will need in production but hasn't hit during Dev-mode testing (e.g. a backup email channel), you can add it manually before promoting. After promotion, allowlist edits take effect within 30 seconds without a redeploy — well-behaved SDKs honor the HTTPS_PROXY environment variable we inject, and the new entry propagates through VM metadata to Envoy on the next config reload. Worked examples for Stripe, SendGrid, OpenAI, Twilio, S3, Segment, and Slack webhooks are in docs/outbound-containment.md §8.
Not with the managed offering, because we host the database ourselves as part of the 5-VM topology — the observer VM needs to subscribe to the database's own replication stream, and that only works when we run the database. If you want to keep using a managed database you already run, clone the open-source server/ repo on GitHub and run the proxy yourself in front of it. Self-hosted is free forever, and the chain format is the same.
Roughly 8–12 minutes end-to-end: VPC creation, replica VM provisioning, observer VM provisioning, chain storage bootstrap, Cloud Build for your app (if you opted in), Cloud Run deploy, and Google-managed TLS certificate issuance for the custom domain (if you opted in).
Yes. Prisma, Drizzle, SQLAlchemy, Mongoose, ActiveRecord, JDBC, raw drivers — they all work. The proxy speaks native Postgres and MongoDB wire protocols, so any ORM or driver that talks to those databases works unchanged. The proxy is invisible to your application code.
Single-digit milliseconds for normal user queries, because the proxy just forwards bytes for non-admin traffic with zero parsing. Admin-flagged queries get parsed and emit an event to NATS, which adds another ~1ms. Chain writes happen asynchronously after the response is returned, so your app never waits for the transparency layer.
Yes. The topology is the same shape; resizing means adding or removing replica VMs and rebalancing the chain-MinIO quorum. We don't have a one-click resize yet but it's on the roadmap (see ROADMAP.md v1.1). If you start at 3 replicas and grow into needing a stronger quorum or larger VMs, talk to us and we'll do it manually.
Yes, and it's free forever. The entire reference implementation — Rust proxy, chain engine, NATS pipeline, dashboard, Terraform modules — is open source under AGPLv3 in the server/ repo on GitHub. This site sells managed hosting of that open-source software. The code is the trust anchor; you can audit it yourself.
No. It uses Merkle hash chains, which are the same cryptographic primitive blockchains use for tamper evidence, but there is no consensus, no tokens, and no distributed ledger. Each user has their own independent append-only chain. When a user deletes their account, their chain is destroyed and no other user's chain is affected — GDPR-compliant by design.
Every deployment comes with a transparency dashboard at a URL we give you. Your end users can visit it to see every access to their data — app and admin, labeled by identity — and click "Verify My Chain" to run the Merkle verification client-side in their browser via WASM. The server cannot fake a passing result because the verification code runs on the user's machine.