The eighth costume
“We trust our employees” survives a polite conversation. “We trust our LLM” does not survive being said out loud.
Every privacy policy on earth contains a version of the same sentence: we limit access to authorized personnel with a need to know. The sentence has seven costumes already — GDPR, HIPAA, SOC 2, CCPA, PIPL, FERPA, GLBA — and the receipts page quotes each one verbatim. They are all structurally unverifiable because the load-bearing verb is limit, which is a promise about the state of mind of an employee at the moment of access, not a property the affected person can check.
The eighth costume is new. The clause is now being written for autonomous systems: access is restricted to authorized automated workflows. Our AI assistants operate under the same access controls as our employees. The load-bearing verb did not change. The problem is that there is no state of mind to check — the process holding the credential is not a person, and the category of “authorized” becomes a definition the company writes for itself. The gap between what the policy promises and what the architecture enforces, tolerable for forty years of human admins, becomes a canyon in the next eighteen months of autonomous ones.
The EU AI Act is the first regulation that writes this obligation into law with a deadline. Article 12 creates the logging requirement. Article 19 creates the retention requirement. Full application for high-risk AI systems is August 2, 2026. Penalties reach €15M or 3% of global annual turnover, whichever is higher.
What Article 12 actually requires
Article 12(1), verbatim from Regulation 2024/1689:
High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.
Article 19(1), verbatim:
Providers of high-risk AI systems shall keep the logs referred to in Article 12(1), automatically generated by their high-risk AI systems, to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law.
The load-bearing word is automatic. A log written by software that can be disabled by the same team being audited is not “automatic” in any meaningful sense — it is an opt-in feature the provider elected to operate. The current vendor answer across the industry is pgaudit plus an ELK stack plus an attestation that the logs are complete. That posture satisfies the letter of Article 12. The spirit is a harder problem, and it is the one Article 99(5) penalties are designed to push providers past.
What "automatic, tamper-evident, user-verifiable" means structurally
Automatic— the proxy intercepts wire-protocol traffic. Every query the database receives becomes a chain entry before the database itself sees the query. There is no configuration surface for “log this but not that,” because the logging is a property of the deployment topology, not a feature the operator enables.
Tamper-evident — each event is hashed into a per-user Merkle chain. Modifying any entry breaks every entry after it, detectable in a single pass by anyone with a copy of the chain. The chain is not immutable — nothing on a running system is truly immutable — it is tamper-evident, which is the property that matters for accountability.
User-verifiable— and this is the load-bearing property of the entire product. The verification code runs on the affected data subject’s machine, in their own browser, compiled to WASM from the same Rust source as the server-side verifier. The server cannot fake a passing result because the server is not running the verifier. This is the stake in the ground: the user verifies it, not the CISO. Every other audit tool in the category logs for the company being audited. We log for the person whose data was touched.
How to integrate
The proxy speaks native Postgres, MongoDB, and S3 wire protocols. Agent frameworks that use standard database drivers do not need code changes — you swap the connection string, and the agent’s tool calls become chain entries automatically. For frameworks that expose a tool-use abstraction layer, additional metadata (tool_call_id, model name, framework name, prompt hash) is captured when available and stored alongside the wire-protocol event.
Example: an MCP host pointed at the proxy via mcp.json:
{
"mcpServers": {
"uninc-db": {
"url": "https://proxy.your-deployment.unincorporated.app/mcp",
"env": {
"AGENT_LABEL": "agent:triage-bot",
"MODEL": "claude-3-7-sonnet"
}
}
}
}Example: a LangChain agent using the standard Postgres tool with the proxy endpoint injected at deploy time — your code does not change, the connection string does:
from langchain_community.utilities import SQLDatabase
from langchain.agents import create_sql_agent
# os.environ["DATABASE_URL"] is injected by the control plane
# and points at the transparency proxy, not the raw database.
db = SQLDatabase.from_uri(os.environ["DATABASE_URL"])
agent = create_sql_agent(llm=..., db=db, verbose=True)
# Every tool call the agent issues becomes a chain entry
# labeled with the agent credential, model, and tool_call_id.
agent.invoke({"input": "How many new patients this week?"})The example snippets above assume the MCP server adapter and agent-aware schema ship with server/ v1.1. The wire-protocol proxy and chain engine are already in production; the adapter extends them with MCP tool-call metadata capture. Track the reference implementation at github.com/un-incorporated/server.
What we are not
The AI audit category is crowded. A few things this is not, and what each adjacent category does instead.
Not an MCP gateway
Tetrate, MintMCP, and HashiCorp Boundary operate at the MCP gateway layer — they inspect tool calls flowing through an explicit gateway. An agent that bypasses the gateway and uses raw Postgres credentials is invisible to them. We watch the wire protocol, so we see both.
Not a prompt-trace observability tool
Langfuse, Braintrust, LangSmith, and Helicone log what the model said. We log what the database actually served. Your auditor will eventually want both: a prompt trace to understand intent, a database chain to verify effect. Adjacent, complementary, not competing.
Not an agent credential vault
HashiCorp Vault and similar tools manage the issuance of credentials. We audit their use. Orthogonal — the right deployment has both: a vault that mints short-lived agent credentials, and a chain that records every query those credentials issue.
Not a model-evaluation or interpretability tool
Anthropic’s interpretability research, Lakera, Robust Intelligence, and the alignment community work on whether an AI should do a thing. We record what it did at the database layer. If your agent has database credentials, we are the accountability layer your existing AI-safety stack does not touch.
Why open source matters here
AGPLv3. The full reference implementation — Rust proxy, chain engine, replica verifier, dashboard, Terraform — lives in the server/ repo. You can read it. You can run it. You can fork it. The reason this cannot be closed source is structural: if we kept the verifier secret, we would be asking your users to trust us not to lie about what the verifier does — exactly the failure mode the product exists to prevent. The code is the trust anchor.
Deploy in under fifteen minutes
The managed service hosts your database behind the transparency proxy in a dedicated per-deployment VPC in our GCP project. Every paid deployment gets the same 5-VM topology — 1 proxy + N replicas with chain-MinIO sidecars + 1 independent observer VM that reads the database's own replication stream and cross-verifies the proxy's chain. Hosting your app alongside the data layer is an optional checkbox at onboarding, not a separate tier. The chain logs human admin and AI agent traffic identically — it does not care who issued the query.