We don't prevent access.
We make it undeniable.
Every query through the proxy is tamper-evident and user-visible. We log everything that reaches the database; we cannot prevent everything that reaches a screen. Pick a deployment tier below to see which scenarios we catch, which we only surface, and which remain genuine gaps.
We host the 5-VM topology in our GCP project: proxy VM, three database replica VMs with chain-MinIO sidecars, and an independent Observer VM that reads the database’s own replication stream. v1 ships with one observer — meaningful hardening over proxy-only designs, not yet multi-observer Byzantine quorum.
SELECT email, phone FROM users WHERE id = 42
Same, and the admin has no way to skip the proxy — chain-MinIO quorum and the Observer VM both record it.
SELECT * FROM users — or pg_dump through the proxy
Same, plus chain-MinIO quorum storage and the Observer VM cross-check the export from the database’s own WAL.
UPDATE users SET email = '...' / DELETE FROM users WHERE ...
Same, plus quorum storage + Observer VM cross-check the mutation against the replication stream the database actually applied.
Metabase, Retool, or Looker connecting with admin credentials
Same.
psql postgres://admin:pass@raw-db-host:5432/mydb
Blocked. Database replica VMs sit on the private subnet with no public IP and no SSH daemon. Firewall allows only the replication stream and chain-MinIO sidecar traffic from the proxy and Observer VMs. And if the proxy lies about what it forwarded, the Observer VM reads the database’s own WAL and catches the mismatch.
CREATE USER shadow_admin — queries as that user aren't in uninc.yml
Blocked. CREATE USER goes through the proxy and is logged; connections from unknown users on non-app sources are automatically flagged as admin traffic. The Observer VM independently confirms the operation from the replication stream.
A malfunctioning retrieval agent re-reads a user’s history on every tool call, producing a storm of access events
Same, and the Observer VM independently confirms each access from the replication stream. Same roadmap gap on automatic alerting.
A compliance review needs: agent query volume, which models, which tool-call ids, per user
Same, plus per-agent run grouping (agent_run_id) lets the auditor collapse 1000 individual queries into one agent task. Available once server v1.1 ships the ActorType::Agent schema — see ai-governance-reframing.md §5.
A script reads one user per hour for weeks to stay under the radar
Same. The data to detect it exists in the chains and in the Observer VM’s independent replay of the replication stream. The tooling to surface the slow pattern doesn’t yet.
Clipboard, local CSV, email, paste into ChatGPT
Same. Accountability, not DRM.
Print screen, phone photo of monitor
Same.
ssh root@server → modifies proxy config, deletes chain files
Customer has no SSH on any VM. Proxy VM SSH is restricted to our admin CIDR and chain-logged; DB replica VMs and the Observer VM have no SSH daemon at all. Chain-MinIO quorum across replicas catches silent history rewrites; the Observer VM reading the database’s own WAL catches a proxy that lies about what it forwarded. v1 ships one observer — meaningful hardening, not yet multi-observer Byzantine quorum.
Fork the repo, remove event emission, deploy the silent version
We pin the proxy image hash and roll out updates from our build pipeline, so a modified proxy would require compromising our internal supply chain. A silent proxy is also visible to the Observer VM: the Observer reads the database’s own replication stream, so operations the proxy never logged still show up in the Observer’s chain and the mismatch fires an alert.
pg_basebackup to a storage bucket, restoring a snapshot on another machine
We hold backup access on your behalf. Backup operations don’t flow through the proxy, so they aren’t on the per-user chain. Backup access by our ops team is logged into a separate operational audit trail; we’ll surface that to you on request. Honest gap.
The person with root and the person with admin agree to hide activity
Much harder — chain-MinIO quorum means the operator must compromise a majority of replica VMs across separate network zones, and the Observer VM (provisioned with credentials separate from the proxy’s) still reads the database’s own WAL. drand-seeded verifier rotation makes pre-compromise harder. The honest v1 limit: a fully compromised operator cloud account could still coordinate all of it. Not a proof — a raised bar.
A LangChain agent, manipulated by a user message (prompt injection), queries another customer’s records
Same. The chain entry exists and is labeled, and the Observer VM confirms the operation from the replication stream. Detection of the prompt-injection pattern itself is a model-evaluation problem, not a logging problem.
Agent reads patient records, then POSTs them to an attacker-controlled webhook
Caught by the outbound containment runtime when the “host my app” checkbox is enabled — every outbound destination the customer app reaches is chain-logged as an OrgCategory::Egress event. Shipping in v1.1 per docs/outbound-containment.md; today’s v1 deployments cover the database layer only.