What it does
Context Data's InterLock sits between AI agents and the data they use. Agents connect to it instead of connecting directly to databases, files and APIs. It speaks the Model Context Protocol, the Postgres wire protocol and HTTP, so adoption is described as a connection-string change rather than a code change. Every request is checked against a role and policy. Roles can allow or deny access per source and, for SQL sources, per table and column. SQL is parsed before it runs and anything not allowed is refused. Personal data in results is masked before the agent sees it, and policies can also rate-limit an agent or cap the risk of its writes. Writes are classified by risk. Routine inserts pass, while updates, unbounded deletes and schema changes are queued for a person to approve or reject in a console, with an optional Slack notification. Each request, allowed or denied, is written to an append-only audit log that can be exported as CSV. It deploys inside your own environment with Docker Compose or Kubernetes with Helm. The site lists PostgreSQL, MySQL, Amazon S3, Slack, GitHub and HTTP APIs as data sources, and says Claude Code, OpenAI and Gemini agents were tested end to end while any MCP agent can connect. A status section marks 13 capabilities as public beta, one as disabled and three as planned.
Capabilities
- Per-agent identity and keys with role-based access down to the column
- Masking of sensitive values in results before the agent sees them
- Approval queue for risky writes such as unbounded deletes
- Append-only audit log of every allowed or denied request
- Works over MCP, the Postgres wire protocol and HTTP
- Runs in your own environment with Docker Compose or Helm
When to use it
- You are giving AI agents access to production databases and want column-level limits
- You need sensitive fields masked before an agent can read them
- You want a person to approve destructive or high-impact writes
- You need an audit trail of what each agent requested
