InterLock is a proxy between AI agents and your databases, files and APIs. It authorizes every request by role and policy, redacts sensitive fields before the agent sees them, holds risky writes for approval and audits everything. Your agents and your data stores do not change.
Served from cachePassed to originHeld for approval
Supported by
Why a data layer
Agent platforms decide which tools an agent may call. Nothing decides which rows those tools may read.
Two layers need controls once agents reach production. The first is identity and tool permissions, and good products already cover it. The second is the data itself: the query that runs, the rows that come back and the write that changes them. InterLock works there, on the protocols your data already speaks.
tool_call query_database(
SELECTname, plan, ssn
FROMsales.customers
LIMIT 50
)
tool_call query_database(
DELETE FROMsales.orders
)
Layer 1 · ToolsMay this agent call query_database?Answered by identity and tool platforms. Yes, twice.
Layer 2 · InterLockWhich tables and columns? Is this write safe?
sales.customers is granted to this role
ssn is masked before the agent sees it
DELETE with no WHERE is held for a person
What InterLock does
Four controls on every request an agent makes.
01
role analyst
sales.customers.nameallow
sales.customers.planallow
sales.customers.ssndeny
sales.payroll.*deny
everything elsedeny
Access by role, down to the column
Each agent gets its own identity and key. Source roles allow or deny actions per source, and for SQL sources per table and column. SQL is parsed before it runs, and anything a role does not allow is refused.
Deny by default
02
Database returnsAda Moreno · pro · 123-45-6789
InterLock
Agent receivesAda Moreno · pro · [REDACTED:US_SSN]
Redaction before the agent sees it
Personal data in results is detected and masked in the response. Policies can also redact named columns, rate-limit an agent or cap the risk of its writes. Policies only ever narrow access; they never grant it.
Masked in the response
03
Risk highAwaiting approval
DELETE FROM sales.orders;
No WHERE clause. Requested by analyst-agent over MCP.
ApproveReject
Risky writes wait for a person
Every write is classified by risk before it runs. Routine inserts pass. Updates, unbounded deletes and schema changes are queued for a reviewer, who approves or rejects them in the console, with an optional Slack notification.
Allowed or denied, each request is written to an append-only audit log with the identity, the source, the decision and what was redacted. Admin actions are audited too, and the log exports as CSV.
Append-only audit log
How it works
Deploys as infrastructure inside your environment.
Agents connect to InterLock instead of connecting to your data stores. It speaks the protocols they already use: the Model Context Protocol, the Postgres wire protocol and HTTP. Adoption is a connection-string change, not a code change.
RequestResponse
01 · IdentityResolve who is askingThe agent's key is checked on every request.
02 · AccessEvaluate roles, policy and riskSource roles, then policy, then the risk of any write.Denied, with the reasonRisky write held
03 · CacheServe if seenRepeat queries answered from a cache scoped to each identity and source.Hit: answered here
04 · RoutePass throughOn a miss, a governed connection to the origin.
05 · RedactProtect the resultSensitive values masked before the agent sees them.
06 · RecordLog everythingAn audit entry for every request, allowed or denied.Every path ends here
Docker ComposeKubernetes with HelmSigned release imagesRuns next to your data
What it works with
The agents you use, and the data you already have.
Agents and clients
Claude Code
Any MCP client
psql and asyncpg
HTTP clients
InterLockMCP · Postgres wire · HTTPone key per agent
Infrastructure in the path of production data has to be trusted, so every capability carries a status and the evidence behind it. If something is not ready, the status page says so.
