context.data
Talk to us
Menu
Papers & Blog
Blog

Introducing InterLock

AI agents are ready to work with your real data. InterLock decides what they can see and what they can change, and keeps a record of all of it.

The Context Data team 5 min read

Picture a support assistant built on Claude or GPT. A customer asks when their last order shipped. To answer, the assistant needs your orders database, so somebody gives it a connection string.

That connection string works like a master key. The login that reads one order can read every customer's email address, and depending on how it was set up, it can change or delete rows too. The assistant will usually behave. "Usually" is a hard thing to sign off on when the data belongs to your customers.

This is where many teams stall when agents move from demo to production. The model is capable and the data is ready, and the only thing standing between them is a password.

A front desk for your data

InterLock is an open-source gateway that sits between AI agents and the systems they use: databases such as PostgreSQL and MySQL, files in Amazon S3, internal APIs, and tools like Slack and GitHub. Agents connect to InterLock instead of connecting directly. InterLock holds the real credentials, and each agent gets its own InterLock key.

Think of the front desk in an office building. Visitors never get a master key. They sign in, receive a badge for the floors they need, and the desk keeps a log of who went where. InterLock does the same for every query and API call an agent makes.

Agents such as Claude Code, OpenAI, Gemini and other MCP clients connect to InterLock, which identifies the agent, checks roles and policy, redacts sensitive data and holds risky writes, logs every request, then reaches PostgreSQL, MySQL, Amazon S3 and internal APIs. AGENTS YOUR DATA key real login Claude Code OpenAI Google Gemini Any MCP client PostgreSQL MySQL Amazon S3 Internal APIs InterLock 1Identify the agent 2Check roles and policy 3Redact sensitive data 4Hold risky writes AUDIT LOG: EVERY REQUEST
Figure 1. Agents keep their tools and swap a password for an InterLock key. InterLock holds the real logins and checks every request on the way through.

What happens to each request

Every request goes through the same steps before anything reaches your data:

  1. Who is asking. The key identifies the agent, so every action is attributed to it, and its access can be revoked from the admin console at any time.
  2. What it may touch. Roles grant access to a source and can narrow it to specific tables or columns. Policies add limits on top, such as blocking a table or capping how risky a write may be. A request that nothing allows is refused.
  3. What comes back. Results are scanned for personal data such as email addresses and Social Security numbers, which are masked before the agent sees them.
  4. What changes. Writes are graded by risk. Adding a row usually goes straight through. Updating or deleting rows waits until a person approves it.

Every request, allowed or refused, lands in an audit log.

Three requests, three outcomes

Here is a read-only analytics agent at work, followed by one that is allowed to make changes.

analytics-agent · read onlyAllowed, redacted
SELECT name, email, plan FROM customers LIMIT 3;
Ada Park [REDACTED:EMAIL] team Ben Okafor [REDACTED:EMAIL] free Chloe Varga [REDACTED:EMAIL] enterprise
analytics-agent · read onlyDenied
DELETE FROM orders WHERE id = 1;
Source role denied. Nothing reached the database.
billing-agent · may writeHeld for approval
UPDATE orders SET status = 'refunded' WHERE id = 1042;
Queued for a reviewer. Not executed; do not retry.
Figure 2. The same gateway, three different answers. Names and data come from InterLock's sample shop database.

The first query returns real rows, with each email address masked. The second never reaches the database, because the agent's role only allows reads. The third is held: a reviewer sees the exact statement, which agent sent it and how risky it is, and approves or rejects it. An approved change runs exactly once, and the agent is told not to retry while it waits.

Works with the agents you already use

InterLock speaks three protocols agents already understand: the Model Context Protocol (MCP), the PostgreSQL wire protocol and plain HTTP. We have tested it end to end with Claude Code, OpenAI's Codex and Responses API, and Google's Gemini, and any MCP client can connect. A database tool like psql connects with the InterLock key as its password. The agent itself does not change. Only the address and the key do.

What it does not do

InterLock governs the traffic that passes through it. If an agent also holds its own database password, that path is outside InterLock's view. SQL checks read the statement an agent sends, and a database view or function can reach further than the statement shows, so the login InterLock uses upstream should stay limited too. We publish the status of every capability, including what is still in beta.

Try it

InterLock is open source under the Apache 2.0 licence and runs on your own infrastructure, with Docker Compose or Kubernetes. One command starts it on a laptop with a sample shop database:

git clone https://github.com/ContextData/interlock
cd interlock
docker compose --profile quickstart up -d --wait

In about ten minutes you will have run a governed query, seen an email address masked and watched a delete get refused.

Read the quick start View on GitHub Let's discuss your deployment
All papers and posts Context Data