AGENT INTERLOCK

An independent MCP server that prevents conflicting actions when multiple AI agents operate on shared resources

Identity says who.
Interlock says when.

MCP gives your AI agents hands. Every MCP server you connect is one more way for an agent to change a listing, an order or a customer record — and two agents, some you built and some you bought, can reach the same one. Nobody owns that collision. Interlock does.

Interlock prevents conflicting actions when multiple AI agents operate on shared resources — whether those agents are supervised, running under a person's account in a desktop assistant or a coding tool, or autonomous, running as services. Both ask the same way, and both are held to the same answer.

Interlock is itself an MCP server. Add it beside the MCP servers your agents already use, with no SDK to build in. Before an agent acts on a shared resource it asks, and the answer is grant, wait or deny — bound to the identity of the agent, or of the person it acts for. Your systems act only on a grant, and afterwards the decision is yours to retrieve as signed proof.

MCP OAuth OpenID Connect

Why not just a lock?

If every agent lives in one application using one database, the database's own locks are the right answer, and you do not need Interlock. The problem starts when they don't: agents from different teams, frameworks and vendors reaching the same records through different systems and different MCP servers, with no one arbiter they all trust and all actually call.

A row lock, a Redis key, a lock inside one MCP server where it stops
  • Works only where you own the code. A bought agent, or one on another team's stack, cannot take a row lock in your database or a key in your Redis.
  • Sees only what it fronts. Two agents reaching the same record through two different MCP servers never meet at either one's lock.
  • The holder is a session or a random token, not a proven identity. Nothing says who is actually holding it.
  • Leaves no signed record that another system can verify — who was allowed to act, on what, and when. Building one means running your own lock service and distributing its keys.
Interlock consider it when
  • Agents from more than one team, framework or vendor act on the same records — listings, orders, bookings, customer accounts — often through more than one MCP server.
  • You want one answer that every MCP-capable agent can ask, with no client code to write, ship and keep current in each framework.
  • Agents have already collided, and a customer saw the result.
  • You need proof of which agent was allowed to act, on what and when — for an audit, or for the next incident.

Add it like any other MCP server

Interlock is a hosted MCP server. Add it to whatever your agents already run in: an assistant such as Claude or ChatGPT; a coding tool such as Claude Code, VS Code, Cursor or Codex; an agent platform such as Copilot Studio, Azure AI Foundry or Amazon Bedrock; or your own code on frameworks such as the MCP SDKs, LangChain, Semantic Kernel or Spring AI. If it speaks MCP, it can ask before it acts. Nothing to build in, nothing to ship with each agent, nothing to keep current.

Lock, then act the agent
  1. Lock. Before it touches a shared record, the agent asks Interlock. The answer is grant, wait or deny.
  2. Act. On a grant, the agent calls the resource as it would have anyway, passing along a reference to the grant.
Check, confirm, prove the resource, then you
  1. Check and confirm. At the moment it acts, the resource checks the grant reference with Interlock, and confirms the outcome when it has. This step is the guarantee: an agent that never asked, or skipped the step, is stopped because the resource refuses to act without a grant.
  2. Prove. Afterwards, the decision is yours to retrieve as a signed document that anyone can verify without asking Interlock — long after the moment has passed.

Where Interlock sits

Before an agent changes anything, five questions get answered. Four stay with your estate. Interlock answers one — and your systems enforce its answer.

Identity
Who are you?
YoursPKI or IdP
Access control
Are you allowed to reach this at all?
YoursIAM or policy engine
Authority
Given what is happening right now, may you act?
OursAgent Interlock
Enforcement
Did the agent get a grant before it acted?
Yoursyour MCP server or system
Workflow
What happens next — which agent, in what order?
Yoursorchestrator or agent framework

Interlock is not an identity provider, not an access-control system and not a workflow engine, and it replaces none of the ones you run. It answers one question, at the moment an agent asks.

Who and when, separately proven

Your identity provider says who an agent is. Interlock says whether it may act right now. Two answers, two chains of trust, one record of both.

OAuth / OpenID Connect who is asking
The agent brings the identity it already has. A service signs in with OAuth; an agent acting for a person signs that person in at your own identity provider over OpenID Connect. Every answer Interlock gives is bound to that identity.
MCP when it may act
Before it changes a shared record, the agent asks through Interlock's MCP tools and gets one of three answers: grant, wait or deny. One agent holds a resource at a time; the next is told to wait, and for how long, instead of finding out by overwriting it. Your systems act only on a grant.

What you can show afterwards

After something goes wrong, anyone entitled to proof of the lock asks one question: what happened, and who was allowed to do it? Interlock keeps that evidence as it goes, so nobody has to assemble it afterwards.

For the incident review the record
Every ask is answered and kept: which agent, proved how, for which resources, the answer, and the outcome. Both sides keep the same record, and a grant that was issued can be verified without asking Interlock.
For the integrator MCP
The agent asks for permission, and only a reference to the grant travels with the action, whichever MCP client it runs in. The system that makes the change checks that reference with Interlock before acting. The proof sits with your systems as much as with Interlock, and nobody has to reconstruct who held what from logs.

Pending General Availability

Agent Interlock is built and operated in the United Kingdom.