Inlock sits between your agents and the tools they call, deciding per action: proceed, wait for a named person to sign off, or block. Every decision leaves a record an auditor can verify.
Every AI guardrail on the market checks whether text is toxic or leaks PII. None of them notice when an agent with real tool access drops a table, sends money, or leaks a record — because that was never text in the first place. This isn't hypothetical:
Replit's AI agent deletes a live production database — during a code freeze
The Register · Jul 2025An AI agent guarding a $47,000 crypto pool is talked into paying all of it out
Cointelegraph · Nov 2024Asana's MCP server shows ~1,000 customers' data to other organisations
BleepingComputer · Jun 2025Repositories using an AI coding assistant leak secrets 40% more often
GitGuardian · Mar 2025One classifier, generic across every MCP server — pattern matching resolves most calls instantly with no network call at all; an LLM only judges the rare, genuinely novel one, cached after the first time.
Every tool call an agent makes passes through Inlock on its way to the tool. Inlock returns a verdict — the integration surface is what actually runs, or doesn't run, the call. Only an allow reaches your systems.
Three ways in, one engine behind them: an in-process wrapper for code you own, a hook for Claude Code, an MCP gateway for everything else. The same gates, the same trail, whichever door the call came through.
Four-eyes control for agents: a named person signs off what is risky, the auditor reads the proof, the manager sees what is waiting and what it costs, and engineers wire it in for free. One engine, one audit trail.
Databases, external communication, financial transactions — each classified the instant the call is made: let it through, hold it for a human, or block it outright. The check runs before the call does, in a fraction of a millisecond, which is what makes a held call one that has not happened yet rather than one you are reading about afterwards.
What actually decides is a gate you write: a pattern to match, a condition that has to be true, an action to take when it is. Write one from scratch — templates are just a faster way to get to the same place.
A gate also says what happens when nobody answers. The default is deny, so nothing slips through because a reviewer was at lunch — but a gate may choose to allow instead, after a number of seconds it sets. That is the only way an unanswered call ends in allow, it is decided in advance, and the trail records it as the gate's decision rather than as a person's or as an expiry.
Seven of them — database, network, financial, PII, shell execution, regulated actions, content moderation. Duplicate one and override what you need. The same picker you'd see in the product, and the same engine as the builder above, just pre-filled.
Every allow, hold, and deny — a timestamped entry whose hash covers its own fields plus the entry before it. Recomputing every hash from scratch is how tampering gets caught, not just a promise about the log.
Beside it sits a second record: who changed the org chart, a team, a member, an API key or the branding, who signed in, and who exported the trail. Administration is answerable too. Both are admins-only to read.
Real token usage, read from wherever it actually exists — a local transcript, or reported directly by the agent itself — aggregated per agent and per model, not estimated after the fact, and carried forward over a month, a quarter or a year.
Everyone signs in, and the org chart decides what they see: your own agents, plus everyone's below you. A manager gets their reports' fleet — what's running, what got denied, what's waiting on a decision — and approves or denies through the same engine and the same audit log as the main dashboard.
From here they can apply a gate across every agent the team runs in one action, closing off a class of risky calls instead of approving them one at a time. Worth building: only 7.2% of organizations name anyone formally accountable for agent behaviour (Gravitee, 2026).
Roles aren't a ladder with admin at the top. They're sets of powers, because the role an auditor needs cannot be expressed as a rung: they read the whole trail, which only an admin could, and they must never decide a held call, which almost everyone else can.
So an Auditor's dashboard has no approval queue — not hidden in the page, absent from the API and never streamed to them. Someone reviewing decisions after the fact was never in a position to influence them, and that is enforced by the server, not by a convention.
Every workspace also carries its own second record: who changed the org chart, a team, a member, an API key or the branding, who signed in, and who took the trail out of the system.
No public release yet — this is where to hear about it first. A few lines is plenty; we read every one ourselves.
Pre-release, and there is no sales team: whoever replies is the person who built it.