AGENT INTERLOCK

An independent authority that stops AI agents taking conflicting actions

Identity says who.
Interlock says when.

Your AI agents act on their own — some you built, some you bought — and two of them can reach the same listing, order or customer record. Nobody owns that collision. Interlock does.

Before an agent acts on a shared resource, Interlock checks two things, in order. Who is asking: the agent's own identity, proved the way your estate already proves it. Then when it may act: is that resource free right now, or already held under another agent's grant? One agent holds a resource at a time, no matter which agent asks or which route it comes by. If a resource is really several of something — four bays, ten concurrent calls — you set that number, and that many may be held at once.

The answer is a signed grant to proceed or a signed refusal, bound to the asking agent's own identity — and both sides keep the same record.

X.509 SPIFFE OAuth 2.0 API key

Where Interlock sits

Before an agent changes anything, four questions get answered. Three may already have an owner in your estate. Interlock answers the fourth, and only the fourth.

Identity
Who are you?
YoursPKI, SPIFFE 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
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 never starts anything and never calls an agent back. It answers one question, at the moment an agent asks.

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, with no one arbiter they all trust and all actually call.

A row lock, a Redis key, a queue 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.
  • 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.
  • 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.

Who and when, separately proven

Identity and authority are separate chains of trust. Interlock adds the second: a signed JWT grant that proves when an agent may act.

X.509 / SPIFFE / OAuth 2.0 / API key who is asking
Bring the identity your agents already carry: an X.509 certificate from your own PKI, with or without mTLS; a SPIFFE SVID from your trust domain, verified against the bundle you publish; OAuth 2.0 client credentials; or an API key. One endpoint accepts them all. Where an agent has nothing yet, Interlock issues it a certificate, client credentials or an API key, so nothing waits on PKI. The decision is the same whichever an agent presents; only the strength of the binding is recorded.
JWT when it may act
Interlock's answer is a short-lived JWT access token bound to the identity that asked: a signed grant to act now on the named resources, a signed not yet with a retry time, or a signed no. The receiving system verifies it against Interlock's published keys — no call back — and the action runs directly between your systems. While a grant holds, any other agent asking for the same limited resources waits, or is refused.

Closed loop, not grant and forget

A grant locks every resource on the route together, and the lock is released only when the receiving side confirms receipt back to Interlock — the final receiver by default, or each step as it clears. No agent frees a resource for itself. If no confirmation arrives, the hold stands and an operator is alerted; a timed release is your choice, never the default.

Pending General Availability