Console
← Back to docs

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.

Caught & blocked8
Visible, not prevented9
Not covered0

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.

The honest position: none of these tiers eliminate trust entirely. What happens after data reaches an admin's screen is beyond any database tool's control. Anyone who tells you otherwise is selling theatre.