AI agents are getting a lot more useful because they can now reach for tools through systems like the Model Context Protocol (MCP). But that raises a question we couldn't stop thinking about:
What happens if a tool your agent already trusts quietly changes after it's been approved?
That question is what got us building Trust Cop — an MCP security agent built with TrueForge.
The Problem
When an agent uses an MCP tool, the tool's definition is part of what makes it trustworthy in the first place.
Say a tool starts out looking like this:
text
summarize_pr
Input: pr_number
Purpose: Summarize a pull request
Simple enough. But what happens if that definition changes down the line? Maybe a new parameter shows up out of nowhere:
text
debug: boolean
Or the description and annotations shift without anyone noticing.
An agent shouldn't just assume the new version is safe simply because the old version was approved. That's the gap we wanted to close. Our starting point was pretty simple:
Approved once ≠ trusted forever.
Meet Trust Cop
Trust Cop is an AI-powered security agent that works alongside a custom MCP server we built called Guardian. Three pieces make up the system:
TrueForge — runs the Trust Cop agent itself and handles the runtime, MCP connectivity, sandboxing, and human approval.
Guardian — the actual security boundary, watching MCP tool definitions for changes.
Target MCP Server — the server providing the tools the agent uses day to day.
┌─────────────────────┐
│ TrueForge │
│ Trust Cop │
└──────────┬───────────┘
│
▼
┌─────────────────────┐
│ Guardian │
│ Baseline + Drift │
│ Detection + Audit │
└──────────┬───────────┘
│
▼
┌─────────────────────┐
│ Target MCP Server │
│ MCP Tools │
└─────────────────────┘
How Guardian Catches Drift
The first time Guardian sees a tool, it saves an approved baseline — the name, description, input schema, annotations, all of it.
From there, Guardian fingerprints that definition and keeps checking the live version against it on a regular cycle. If something changes, Guardian flags the difference and moves the tool into:
text
blocked_pending_review
That's really the whole point: a changed tool never sneaks through to the agent without someone noticing.
Our Drift Scenario
For the demo, we spun up two versions of the target MCP server — a v1 and a v2 — and walked through what happens when one turns into the other. Guardian picks up the change on its next polling cycle.
Two examples of what we changed:
We tweaked get_open_prs — changed its description and quietly dropped its readOnlyHint annotation.
We modified summarize_pr's input schema by adding an optional debug parameter.
Guardian logged both as drift events, exactly as intended.
What Trust Cop Actually Does
Once Guardian flags drift, Trust Cop asks it what's pending and gets back something like:
text
Tool: summarize_pr
Status: blocked_pending_review
Detected changes:
inputSchema changed...
From there, Trust Cop explains what changed in plain terms and asks a human to make the call. That step is backed by TrueForge's built-in human approval mechanism — nothing security-sensitive happens until a person weighs in.
When a Human Says No
If the change gets denied, Guardian keeps that tool blocked and logs the decision.
Here's the flow in a nutshell:
Tool approved
↓
Tool definition changes
↓
Guardian detects drift
↓
Tool is blocked
↓
Trust Cop reviews the change
↓
Human decision
↓
┌───────────────┐
│ │
DENY APPROVE
│ │
▼ ▼
Remain blocked Restore
Worst case, the agent just can't use a tool for a bit. That's a much better failure mode than the alternative — the agent trusting something it shouldn't.
Why TrueForge
Honestly, TrueForge saved us from having to build an entire agent runtime from scratch. It handled:
Agent execution
MCP server connectivity
Model interaction
Human approval
Agent configuration
Sandbox capabilities
Agent tooling and interaction
That meant we could spend our time where it actually mattered — building out Guardian and the drift-governance logic — instead of reinventing the plumbing underneath it.
Keeping a Record
We didn't want security decisions to just evaporate once the agent moved on. So Guardian keeps an audit log of everything:
drift_detected
drift_denied
drift_approved
That gives us a clear paper trail of what changed and what got decided — which matters a lot for a security tool. You want to be able to look back and see exactly what happened, not just trust that it did.
What We Took Away From This
The biggest realization for us: tool security isn't just about what a tool does — it's about whether you can still trust its definition over time. Those are two different problems, and it's easy to only think about the first one.
We also came away convinced that the security boundary needs to live outside the agent itself. Trust Cop can reason about a situation and explain it, but it's Guardian doing the actual enforcing. Keep those separate and you get something sturdier:
Agent reasoning
+
Security enforcement
+
Human approval
=
More controlled agent behavior
Where We're Headed Next
A few things on our list:
Smarter risk classification for tool changes
More detailed security reports
Better ways to visualize a tool's history
Policy-based auto-approval for low-risk changes
Hooking into larger MCP environments
Deeper audit and compliance reporting
Wrapping Up
Agents are getting more autonomous by the day, but that shouldn't mean trust becomes something you set once and forget. The idea behind Trust Cop is honestly pretty simple:
If a trusted tool changes, stop and ask.
TrueForge gave us the runtime and interaction layer, Guardian gave us the security boundary that actually watches for drift and controls it — and together that let us put together a small but genuinely useful security workflow for MCP tool governance.
Trust should be something you keep checking, not something you assume forever.
Built with: TrueForge · TypeScript · Model Context Protocol (MCP) · Node.js · Guardian MCP server · TrueForge human approval workflow.
Top comments (0)