In June 2026, Microsoft described a finance-team AI agent that quietly emailed thirty unpaid invoices to an outside address. No one on the finance team approved that action. No password was stolen, no user was tricked, and no obvious access control failed. The problem was subtler: a trusted MCP tool had changed after approval, and the agent treated the updated description as trustworthy instruction.
That is the security problem MCP makes hard to ignore. Most governance processes focus on what happens when a tool is approved. MCP shows that the harder question is what happens after approval, when a tool's description, behaviour, or assumptions change without triggering a fresh review. That gap is what this article calls post-approval drift.
Where the Gap Appears
What MCP Changes
MCP gives AI agents a standard way to discover and use external tools, data sources, and workflows. That makes agentic systems more useful, but it also expands the trust boundary. The agent is no longer acting only on its own prompt; it is also acting on what connected tools tell it.
That matters because the tool description is not just metadata. In practice, it becomes part of the context the agent uses to decide what to do next. If that description changes, the agent may change behaviour even when the original approval decision has not changed.
This is why MCP should be understood as a control surface, not just an integration layer. The protocol helps tools and agents communicate, but the organisation still has to decide which tools exist in the environment, which identities may reach them, and what data they are allowed to expose. MCP makes those decisions operational, but it does not replace them.
What Post-Approval Drift Means
Post-approval drift is the gap between "this tool was reviewed once" and "this tool is still safe today." A tool may be approved at rollout, but later updates can alter its description, scope, or behaviour in ways that no normal governance review will catch.
That creates a false sense of control. The organisation believes it approved a stable capability, while the agent is actually operating in a living environment where instructions can change after deployment. In MCP environments, trust is not a one-time event. It has to be maintained.
The phrase matters because it shifts the governance conversation away from launch-time review. If a tool can change after approval, the true control problem is not onboarding, it is monitoring drift. That is a much harder operational problem, but it is also the one that matters most.
Why This Is Hard to Detect
The reason this issue is dangerous is that every step can look legitimate in isolation. The tool may have been approved. The user may have been acting within normal permissions. The outbound destination may have been allowed. Yet the combination still produces an outcome nobody intended.
That is why this is not just a technical bug. It is a governance failure at the boundary between approval and execution. Traditional review processes are usually designed to answer, "Should we allow this tool?" MCP forces a second question: "How do we know it still deserves that trust?"
A one-time review will not catch a later change in a tool description unless something is actively watching for it. That is the real lesson in the Microsoft example and in the broader MCP security conversation. Security teams are no longer only reviewing code or access lists; they are also reviewing whether trusted instructions have quietly changed.
What the Evidence Shows
This is not an isolated concern. Security researchers have already documented malicious or compromised MCP-related components that used trust in the integration layer to create unexpected outcomes. In one early case, a package used for email workflows added hidden behaviour that copied outgoing mail to an attacker-controlled address after several clean releases.
The pattern is consistent: something was trusted at first, then altered later. That is what makes MCP-related risk so difficult. The danger is not always a dramatic break-in. Sometimes it is a small change in a description, package, or connected server that sits inside a trust boundary the governance process assumed was stable.
That is also why public scanning activity around MCP matters. Security researchers reported sustained internet-wide scanning specifically probing for MCP servers and AI assistant credential files in mid-2026, using correctly formed protocol handshakes rather than simple existence checks. If attackers are probing for these servers at that level of specificity, they are signalling that MCP is becoming a real operational surface, not a theoretical one. Once that happens, governance has to move from documentation to continuous control.
What Governance Needs to Change
AI governance programmes need to treat MCP tools like living assets, not static approvals. Microsoft's own incident response guidance, published alongside the June 2026 case, lays out five controls stripped to their operational core.
A stronger programme also separates trust into layers. The tool itself may be approved, but that does not mean every version, every description, and every downstream action is automatically trusted. Governance has to decide where the line is between a minor update and a material change.
What This Means for AI Governance
MCP is useful because it makes the trust problem visible. Before agentic systems, organisations could often assume that integration risk sat mostly in code, APIs, or access management. MCP shows that the real issue is broader: how agents interpret context, what they are allowed to reach, and how much can change after approval.
That is why MCP is relevant to AI governance, not just security engineering. It exposes the gap between policy and execution. It also shows that governance is not only about who can use AI, but about what AI can do once it is connected to the organisation's systems.
For regulated organisations, that is a material shift. Once an agent can act across finance, operations, support, or knowledge systems, the governance question becomes one of controlled delegation. The organisation is no longer only approving software. It is approving behaviour.
If you are running MCP-connected agents in a regulated environment and want to think through what a monitoring mandate for tool descriptions looks like for your organisation, the email is open.