Most IT teams can tell you exactly how a new AI tool got approved. Almost none can tell you whether it’s still the same tool today.
That gap became concrete on October 6, 2026, when developer Neelagiri Chettiyar launched a free tool called mcpgawk, built after he discovered one of his own approved MCP (Model Context Protocol) servers the connections that let AI agents call out to external tools had silently changed six times since he first approved it, quietly expanding from 85 tools to 103.
BOTTOM LINE: Approving an AI tool once isn’t governance, it’s a snapshot and without a process to re-check it, “approved” silently becomes “whatever this tool now does, which nobody has looked at since.”
WHAT MCPGAWK’S CREATOR FOUND WHEN HE FINALLY CHECKED HIS OWN SETUP
Chettiyar’s own words, from the product’s launch post, frame the problem precisely:
“An MCP server can change what its tools do after you approved it. Your agent will call the new one and never notice.”
He wasn’t speculating he found it happening in his own stack, a server he’d personally cleared, expanding its surface area across six separate updates without triggering any re-review on his end.
WHY “APPROVED ONCE” ISN’T GOVERNANCE FOR AI TOOLS
Traditional software vendor approval assumes a relatively static product: you review it, sign off, and periodic contract renewals are the natural checkpoint for re-review.
MCP servers and many AI tools don’t work that way they can add capabilities, change scopes, or alter what data they touch between releases, often without a formal changelog reaching the people who approved them.
The agent calling that server has no built-in reason to flag the difference; it just keeps working, calling whatever is there now.
This isn’t unique to MCP servers specifically it’s a structural feature of how AI tools are currently built and shipped. Vendors iterate rapidly, often weekly, adding capabilities in response to competitive pressure rather than a specific customer request, and changelog visibility varies wildly between providers.
A traditional annual or quarterly vendor-review cycle, built for software that changes on a predictable schedule, wasn’t designed for tools that can meaningfully change what they do several times within a single review period.
THE DIAGNOSTIC: HOW TO BASELINE AND RE-VERIFY WHAT YOU’VE ALREADY APPROVED
Start by listing every MCP server, plugin, or AI integration currently approved and in use.
For each one, ask:
- Do we have a recorded baseline of what it could do on approval day?
- Would we know today if that changed?
- Who gets notified if it does?
If the honest answer to any of these is “we’d find out if something broke,” that’s reactive discovery, not governance and it’s the exact gap mcpgawk exists to close for a single developer’s setup.
WHY THIS RISK IS BIGGER AT MID-SIZE COMPANIES THAN AT A SOLO DEVELOPER’S
A solo developer like Chettiyar found this drift because he was personally paying close attention to his own small setup.
A mid-size company typically has dozens of approved integrations spread across several teams, each approved by a different person, at a different time, with no shared system tracking what any of them looked like on day one.
The drift problem that took one attentive developer months to notice in a single server compounds quickly across an organization that isn’t tracking baselines at all.
A PRACTICAL STARTING POINT, NOT A FULL SECURITY PROGRAM
This doesn’t require an enterprise security platform to start.
A simple baseline snapshot recorded capabilities, scopes, and data access for each approved AI tool, checked against the current state on a fixed schedule closes most of the gap.
The point isn’t perfect continuous monitoring on day one; it’s converting:
“We’d find out if it broke.”
into:
“We already know if it changed.”
That’s a process decision more than a technology purchase.
THE BROADER PATTERN BEHIND A SINGLE DEVELOPER’S DISCOVERY
What makes Chettiyar’s find worth generalizing isn’t that MCP servers specifically are unusually risky it’s that he happened to be paying close enough attention to his own small setup to notice drift that would be invisible in a larger, more distributed environment.
The same mechanism applies to any AI tool, browser extension, or API integration a vendor can update without a formal notice reaching whoever approved it.
The discovery method here one attentive person, noticing by chance doesn’t scale; a baseline-and-compare process does.
WHERE THIS GOES NEXT
If your team has approved AI tools, MCP servers, or integrations that haven’t been re-checked since the day they were cleared, that’s worth a conversation before it’s worth an incident.
Comment or reach out and we’ll walk through how to baseline what you’ve already got running.
Comments are closed