Runtime trust for MCP tools after approval.
Interlock detects when approved MCP tools drift in behavior, permissions, data access, external reach, or side effects — then quarantines risky changes before agents keep using them.
01approved_baseline:
02 tool: query_customers
03 expected: 403 denied
04
05runtime_probe:
06 tool: query_customers
07 observed: 200 allowed
08
09interlock_decision:
10 drift: effective_permission_expansion
11 severity: critical action: quarantine receipt: chain_verified
Behavioral drift proofExpected denial became observed access.
Same manifest hashSurface stayed stable while behavior moved.
Quarantine decisionRisky tool calls stop before continuation.
Security ReceiptDecision evidence is structured and signed.
Chain verifiedAudit history can be recomputed.
Problem
Approval is not enough.
MCP tools carry permissions, data access, external reach, and side effects. A one-time approval only proves what was reviewed then, not what the agent is allowed to do now.
Tool manifests can stay unchanged while effective behavior changes.
Surface diffing is useful, but it does not prove the approved permission boundary is still true.
Agents inherit runtime access, not screenshots of past approvals.
Interlock checks the observed outcome before risky MCP tools keep executing in the workflow.
Security teams need evidence that survives review.
Every quarantine decision can point to the baseline, probe, drift type, and receipt chain.
Workflow
How Interlock works
A runtime path for teams operating agents against MCP servers and tools they do not fully control.
01
Baseline approved tool
Record the approved MCP surface and expected behavior.
02
Run safe probe
Test behavior in a scoped non-production workflow.
03
Classify drift
Compare observed permissions, data reach, and side effects.
04
Quarantine risk
Hold the tool before agents keep using the changed boundary.
05
Emit receipt
Create structured evidence for the decision and review path.
06
Verify chain
Recompute hashes and prove the audit history stayed intact.
Product console
Inspect runtime trust decisions like code.
The console is built around drift queues, receipt evidence, and MCP inventory review rather than generic alert dashboards.
| tool_name | server_id | expected | observed | decision | severity | receipt |
|---|---|---|---|---|---|---|
| query_customers | crm-mcp | 403 denied | 200 allowed | quarantine | critical | rcpt_8f3a9c2e |
| list_tables | postgres-mcp | allowed | allowed | allow | none | rcpt_1aa45d90 |
| send_update | slack-mcp | known shape | new field | monitor | medium | rcpt_cc82f10b |
| receipt_id | decision | baseline_hash | current_hash | chain | created |
|---|---|---|---|---|---|
| rcpt_8f3a9c2e | quarantine | sha256:92b1...e8f0 | sha256:92b1...e8f0 | verified | 21:04:18 |
| rcpt_1aa45d90 | allow | sha256:a9d2...7bc1 | sha256:a9d2...7bc1 | verified | 21:04:11 |
| server_id | tool_count | owner | external reach | last baseline | trust state |
|---|---|---|---|---|---|
| crm-mcp | 18 | revops-platform | customer data | 21:01:02 | held |
| postgres-mcp | 12 | data-platform | internal db | 20:57:40 | trusted |
| agent_role | tool | policy result | rbac | response scan | next action |
|---|---|---|---|---|---|
| support_agent | query_customers | requires review | expanded | clean | quarantine |
| readonly_agent | list_tables | allow | within role | clean | continue |
Behavioral drift
Same tool. Same manifest. Different behavior.
The strongest proof is the runtime outcome: a tool expected to deny access returns allowed while the approved surface still appears unchanged.
Approved baseline
expected deniedtoolquery_customers
expected403 denied
manifest_hashsha256:92b1...e8f0
approval_stateapproved
Runtime probe
observed allowedtoolquery_customers
observed200 allowed
manifest_hashsha256:92b1...e8f0
drift_typeeffective_permission_expansion
Security Receipt
Every runtime decision leaves evidence.
Interlock receipts connect baseline, probe, decision, and hash-chain verification so security teams can review what happened without reconstructing it from screenshots.
Security Receipt
chain_verified
receipt_idrcpt_8f3a9c2e
server_idcrm-mcp
tool_namequery_customers
expected_outcome403 denied
observed_outcome200 allowed
drift_typeeffective_permission_expansion
decisionquarantine
baseline_hashsha256:92b1...e8f0
current_hashsha256:92b1...e8f0
Manifest hash unchanged. Behavior changed. Runtime held the tool before agent continuation.
Use cases
Built for teams with real MCP blast radius.
Best fit: teams operating agents against tools, gateways, and external MCP servers where permission drift matters more than a static approval screen.
AI-agent teams
Keep tool trust aligned as agents gain data, write, send, deploy, and admin paths.
MCP gateways
Add runtime drift checks before forwarding risky tool calls across shared infrastructure.
Internal platforms
Operate bring-your-own MCP servers with evidence, quarantine, and review paths.
Security engineers
Turn tool trust incidents into concrete receipt evidence instead of ad hoc screenshots.
Honest limits
What Interlock is and is not.
The boundary is intentionally narrow: runtime MCP trust, drift detection, quarantine, and evidence. It is not a broad compliance claim.
Controls MCP tool drift at the agent execution boundary.
It does not replace source scanning, dependency scanning, or app testing.
MCP servers still need auth, validation, isolation, and logs.
Best suited for design partner and non-production proof work right now.
No SOC 2, ISO, HIPAA, or GDPR certification claim is made.
Run one drift check before trusting many MCP tools.
Start with a non-production workflow. Baseline the approved tool, probe the runtime behavior, quarantine drift, and review the Security Receipt.