<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Sakshi Andhale</title>
    <description>The latest articles on DEV Community by Sakshi Andhale (@sakshi_andhale_4e051ec962).</description>
    <link>https://dev.to/sakshi_andhale_4e051ec962</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4101725%2F77cf4d4d-882c-4205-a795-5122906c2583.png</url>
      <title>DEV Community: Sakshi Andhale</title>
      <link>https://dev.to/sakshi_andhale_4e051ec962</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/sakshi_andhale_4e051ec962"/>
    <language>en</language>
    <item>
      <title>Trust Cop: Building a Security Agent for MCP Tool Drift with TrueForge</title>
      <dc:creator>Sakshi Andhale</dc:creator>
      <pubDate>Sun, 30 Aug 2026 18:27:22 +0000</pubDate>
      <link>https://dev.to/sakshi_andhale_4e051ec962/trust-cop-building-a-security-agent-for-mcp-tool-drift-with-trueforge-bpo</link>
      <guid>https://dev.to/sakshi_andhale_4e051ec962/trust-cop-building-a-security-agent-for-mcp-tool-drift-with-trueforge-bpo</guid>
      <description>&lt;p&gt;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:&lt;/p&gt;

&lt;p&gt;What happens if a tool your agent already trusts quietly changes after it's been approved?&lt;/p&gt;

&lt;p&gt;That question is what got us building Trust Cop — an MCP security agent built with TrueForge.&lt;/p&gt;

&lt;p&gt;The Problem&lt;/p&gt;

&lt;p&gt;When an agent uses an MCP tool, the tool's definition is part of what makes it trustworthy in the first place.&lt;/p&gt;

&lt;p&gt;Say a tool starts out looking like this:&lt;/p&gt;

&lt;p&gt;text&lt;br&gt;
summarize_pr&lt;br&gt;
Input: pr_number&lt;br&gt;
Purpose: Summarize a pull request&lt;/p&gt;

&lt;p&gt;Simple enough. But what happens if that definition changes down the line? Maybe a new parameter shows up out of nowhere:&lt;/p&gt;

&lt;p&gt;text&lt;br&gt;
debug: boolean&lt;/p&gt;

&lt;p&gt;Or the description and annotations shift without anyone noticing.&lt;/p&gt;

&lt;p&gt;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:&lt;/p&gt;

&lt;p&gt;Approved once ≠ trusted forever.&lt;/p&gt;

&lt;p&gt;Meet Trust Cop&lt;/p&gt;

&lt;p&gt;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:&lt;/p&gt;

&lt;p&gt;TrueForge — runs the Trust Cop agent itself and handles the runtime, MCP connectivity, sandboxing, and human approval.&lt;br&gt;
Guardian — the actual security boundary, watching MCP tool definitions for changes.&lt;br&gt;
Target MCP Server — the server providing the tools the agent uses day to day.&lt;br&gt;
┌─────────────────────┐&lt;br&gt;
│      TrueForge       │&lt;br&gt;
│      Trust Cop        │&lt;br&gt;
└──────────┬───────────┘&lt;br&gt;
           │&lt;br&gt;
           ▼&lt;br&gt;
┌─────────────────────┐&lt;br&gt;
│       Guardian        │&lt;br&gt;
│  Baseline + Drift     │&lt;br&gt;
│  Detection + Audit    │&lt;br&gt;
└──────────┬───────────┘&lt;br&gt;
           │&lt;br&gt;
           ▼&lt;br&gt;
┌─────────────────────┐&lt;br&gt;
│  Target MCP Server    │&lt;br&gt;
│      MCP Tools         │&lt;br&gt;
└─────────────────────┘&lt;br&gt;
How Guardian Catches Drift&lt;/p&gt;

&lt;p&gt;The first time Guardian sees a tool, it saves an approved baseline — the name, description, input schema, annotations, all of it.&lt;/p&gt;

&lt;p&gt;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:&lt;/p&gt;

&lt;p&gt;text&lt;br&gt;
blocked_pending_review&lt;/p&gt;

&lt;p&gt;That's really the whole point: a changed tool never sneaks through to the agent without someone noticing.&lt;/p&gt;

&lt;p&gt;Our Drift Scenario&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Two examples of what we changed:&lt;/p&gt;

&lt;p&gt;We tweaked get_open_prs — changed its description and quietly dropped its readOnlyHint annotation.&lt;br&gt;
We modified summarize_pr's input schema by adding an optional debug parameter.&lt;/p&gt;

&lt;p&gt;Guardian logged both as drift events, exactly as intended.&lt;/p&gt;

&lt;p&gt;What Trust Cop Actually Does&lt;/p&gt;

&lt;p&gt;Once Guardian flags drift, Trust Cop asks it what's pending and gets back something like:&lt;/p&gt;

&lt;p&gt;text&lt;br&gt;
Tool: summarize_pr&lt;br&gt;
Status: blocked_pending_review&lt;/p&gt;

&lt;p&gt;Detected changes:&lt;br&gt;
inputSchema changed...&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;When a Human Says No&lt;/p&gt;

&lt;p&gt;If the change gets denied, Guardian keeps that tool blocked and logs the decision.&lt;/p&gt;

&lt;p&gt;Here's the flow in a nutshell:&lt;/p&gt;

&lt;p&gt;Tool approved&lt;br&gt;
     ↓&lt;br&gt;
Tool definition changes&lt;br&gt;
     ↓&lt;br&gt;
Guardian detects drift&lt;br&gt;
     ↓&lt;br&gt;
Tool is blocked&lt;br&gt;
     ↓&lt;br&gt;
Trust Cop reviews the change&lt;br&gt;
     ↓&lt;br&gt;
Human decision&lt;br&gt;
     ↓&lt;br&gt;
 ┌───────────────┐&lt;br&gt;
 │               │&lt;br&gt;
DENY           APPROVE&lt;br&gt;
 │               │&lt;br&gt;
 ▼               ▼&lt;br&gt;
Remain blocked  Restore&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Why TrueForge&lt;/p&gt;

&lt;p&gt;Honestly, TrueForge saved us from having to build an entire agent runtime from scratch. It handled:&lt;/p&gt;

&lt;p&gt;Agent execution&lt;br&gt;
MCP server connectivity&lt;br&gt;
Model interaction&lt;br&gt;
Human approval&lt;br&gt;
Agent configuration&lt;br&gt;
Sandbox capabilities&lt;br&gt;
Agent tooling and interaction&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Keeping a Record&lt;/p&gt;

&lt;p&gt;We didn't want security decisions to just evaporate once the agent moved on. So Guardian keeps an audit log of everything:&lt;/p&gt;

&lt;p&gt;drift_detected&lt;br&gt;
drift_denied&lt;br&gt;
drift_approved&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;What We Took Away From This&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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:&lt;/p&gt;

&lt;p&gt;Agent reasoning&lt;br&gt;
      +&lt;br&gt;
Security enforcement&lt;br&gt;
      +&lt;br&gt;
Human approval&lt;br&gt;
      =&lt;br&gt;
More controlled agent behavior&lt;br&gt;
Where We're Headed Next&lt;/p&gt;

&lt;p&gt;A few things on our list:&lt;/p&gt;

&lt;p&gt;Smarter risk classification for tool changes&lt;br&gt;
More detailed security reports&lt;br&gt;
Better ways to visualize a tool's history&lt;br&gt;
Policy-based auto-approval for low-risk changes&lt;br&gt;
Hooking into larger MCP environments&lt;br&gt;
Deeper audit and compliance reporting&lt;br&gt;
Wrapping Up&lt;/p&gt;

&lt;p&gt;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:&lt;/p&gt;

&lt;p&gt;If a trusted tool changes, stop and ask.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Trust should be something you keep checking, not something you assume forever.&lt;/p&gt;

&lt;p&gt;Built with: TrueForge · TypeScript · Model Context Protocol (MCP) · Node.js · Guardian MCP server · TrueForge human approval workflow.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>agents</category>
      <category>security</category>
      <category>opensource</category>
    </item>
  </channel>
</rss>
