Inspiration
I could not stop thinking about one pattern: when an AI agent is given real tools, people often try to control it with better prompts, louder warnings, or a second model checking the first. That is not a safety system. That is hope.
Recent public incidents made the risk concrete: coding agents have been reported to delete production data despite explicit instructions, then generate misleading recovery signals. Prompt injection research has also shown how untrusted content can manipulate an AI system toward data exfiltration. The problem is not that models are useless. It is that a model should not be the final authority over actions that can change systems, expose data, or spend money.
I wanted to build the boring, reliable layer underneath: the thing willing to say no.
What it does
Interlock is a deterministic authorization layer for autonomous agents. It sits between an agent and the tools it can affect. For every proposed tool action in an Interlock-governed workflow, it decides whether that action is allowed.
You describe a task in plain English. GPT-5.6 drafts a typed, least-privilege policy: an explicit list of what the agent may touch for that task. A human reviews and confirms that policy; nothing runs until they do.
After confirmation, every proposed tool action is compared with the approved policy by a deterministic checker.
- Safe, recognized reads are allowed.
- Forbidden, malformed, or out-of-scope actions are halted.
- Irreversible actions escalate to a human reviewer.
Every verdict is visible in a live operator dashboard and recorded as evidence that can be replayed later.
The model is allowed to suggest, but it is never allowed to decide.
How I built it
I built Interlock with Codex, using GPT-5.6 as the coding agent, and kept AGENTS.md and rules.md as the project’s written safety contract.
The architecture has one hard boundary. There are two model-mediated paths: policy drafting and the demo agent. Neither is in the enforcement path.
GPT-5.6 can translate a task into a structured policy draft. The OpenAI Agents SDK powers the contained demonstration agent. Everything that decides ALLOW, HALT, or ESCALATE lives in a small deterministic engine that imports no model client and no network client.
Around that engine, I built:
- A FastAPI backend with a live event stream and SQLite audit log.
- Sandboxed local tools, so the demo cannot touch a real database, filesystem, transfer system, or external service.
- A Next.js safety operations dashboard with a safety overview, policy authority surface, reviewer queue, filterable live decision stream, assurance workspace, and evidence workspace.
- A human-reviewed guardrail workflow: incidents can become candidates, but agents cannot activate their own guardrails.
- Assurance memory: approved failures become replayable regression cases rather than silent policy mutations.
- A fixture-only Multica adapter that produces strict advisory callbacks without contacting a real Multica service.
- Azure and GitHub OIDC deployment foundations that avoid long-lived cloud credentials, while remaining intentionally separate from the local demo.
A 25-scenario safety evaluation runs in CI on every push and pull request. Releases can also produce a tamper-evident local evidence bundle that a separate command-line verifier can validate independently.
Codex wrote much of the implementation quickly because the written project rules made the constraints explicit. The design decisions I kept for myself were the ones that mattered most: the verdict engine must never be an LLM, policy confirmation must be human-controlled, and the engine must remain pure. I then locked that last promise down with a test that fails if the enforcement modules import a model or network client.
Challenges I ran into
The hardest part was discipline. It is tempting to ask a model, “Does this look dangerous?” because it feels intelligent and is easy to build. But that puts probabilistic judgment back into the exact part of the system that must be dependable.
Interlock instead asks a narrower question:
Does this concrete action match the authority a human explicitly approved?
That is a question a deterministic policy engine can answer consistently.
The policy compiler also required careful failure handling. A model-generated draft can be vague, malformed, or incomplete. In that situation, Interlock does not guess. It falls back to deny-all behavior: fail closed, never fail open.
While preparing the public-demo deployment path, I also found a practical systems problem: a static dashboard can become a convincing shell with no reachable API behind it. The deployment design therefore serves the dashboard and deterministic API from one container on one origin, avoiding fragile cross-origin wiring.
Accomplishments that I’m proud of
I am proud that the safety claims are measured rather than asserted.
The evaluation includes 25 scenarios: 10 authorized benign reads and 15 adversarial, malformed, forbidden, or out-of-scope actions. The target is strict:
- Zero dangerous actions missed.
- Zero safe actions incorrectly blocked.
The current evaluation passes that gate.
I am also proud of the separation of authority. The model drafts; the human confirms; the deterministic engine decides. There are no model calls in the enforcement path, so the same action under the same confirmed policy produces the same verdict.
Finally, I am proud that the dashboard does not hide the hard parts. It makes policy authority visible before confirmation, shows halted and escalated decisions in real time, collects reviewer-owned work in one queue, and keeps assurance evidence explicitly report-only.
What I learned
The biggest lesson was about framing. The useful question is not “Is this text malicious?” It is:
Does this action match what the human actually authorized?
The second question can be answered with explicit policy, deterministic checks, and evidence.
I also learned how much a coding agent can accomplish when its boundaries are written down. Codex moved fast precisely because the rules made clear where it could not go. That became the product lesson too: capable agents become safer to trust when their boundaries are explicit and something actually enforces them.
What’s next for Interlock
Next, I want to meet agents where they already live:
- An MCP policy gateway so compatible agents can be governed without changing their code.
- Signed decision and effect receipts for portable audit evidence.
- Strong workload and human-delegation identity.
- Policy versioning, authority diffs, rollback, and reusable safety playbooks.
- A closed assurance loop where every halt, escalation, and human correction can become a reviewed regression test before a policy, tool, or model change ships.
The goal has not changed since the first day:
Make it genuinely safe to put an agent near the things you cannot afford to lose.
Log in or sign up for Devpost to join the conversation.