Blog

Your Internal Audit Plan Needs to Include MCP

Subscribe now to join the Risk Register community:

By Mike Levy, CEO of Cherry Hill Advisory, and Rich Penfil of AssureSwarm.

‍

MCP makes it almost too easy to hand an AI agent the keys to your software and data. Most of that software was built for a person with a login, and it has no idea an agent is on the other end.

‍

That gap sits between the people who build connectors and the people who audit them. The Risk Register is usually me working a risk on my own, but this one needed both sides, so I wrote it with Rich Penfil, who has been building MCP servers since the protocol was released. Rich sees this from inside a build team, in the moment before a connector ships. I see it from inside audit committees and engagement files, which is usually the moment after something failed.

‍

If you do not know Rich, he started as a data scientist at Wells Fargo, working across all three lines of defense. He then moved to PayPal, where internal audit brought him in to build AI into how the team worked. His proofs of concept turned into real, automated audit processes, which is rarer than it sounds. Today he runs AssureSwarm, an agent-native audit management platform.

‍

Neither of us thinks the answer is to slow adoption down. Both of us think the governance around it is nowhere near where it needs to be.

‍

Below is what has already gone wrong, what governed actually looks like, and the five questions I now ask before anyone approves a connector.

‍

Sixty seconds on what MCP is

‍

A language model on its own just produces text. To pull a remediation status, query your audit universe, or update an issue, an agent needs plumbing between itself and your systems. MCP (Model Context Protocol) is often called the USB-C for agents. A system publishes one server, and any compliant agent can use it, including Claude, ChatGPT, Copilot and Gemini.

‍

The server describes each tool in ordinary language. The model reads those descriptions, decides which tool to call, and reads whatever comes back. That is the whole thing. It is also where the risk lives.

‍

This is no longer a niche developer convenience. Anthropic reported more than 97 million monthly SDK downloads and over 10,000 active public servers as of December 2025. An independent pull of the official registry in May 2026 counted 9,652 current server records across nearly 29,000 versions. Gartner projects 40% of enterprise applications will ship task-specific AI agents by the end of 2026, up from under 5% in 2025. A published spec became the default way an agent touches a live system in about eighteen months. Most audit plans get revised more slowly than that.

‍

An AI tool at the hub, enterprise systems on the spokes.

‍

The problem is what the plumbing connects to

‍

"Nobody checks the plumbing until the ceiling is wet," Rich likes to say. MCP is only the plumbing. What matters is the system on the other end of the pipe.

‍

Most enterprise software was designed for a person at a screen. Later it grew an API so scripts could do what the person did. Both designs assume the caller can be trusted, whether that is a logged-in employee or code a developer wrote and someone reviewed.

‍

An MCP connector hands that same API to an agent. The agent reads whatever it is pointed at, including support tickets, email, PDFs and calendar invites, and it treats that text as instructions.

‍

"You built the API for an employee with a login," Rich told me. "You are now handing it to an intern who believes everything they read."

‍

Many vendors simply wrap the existing API in tool descriptions, run it on the user's permissions, and call it governed. User-level permissions answer exactly one question: what the agent can see. They say nothing about what it can be talked into doing. They do not tell you whether it writes straight to the record, or whether anyone can reconstruct what it did afterward. Here is how that has gone wrong in practice.

‍

WhatsApp, April 2025. Invariant Labs showed that a harmless-looking trivia game MCP server, installed next to the legitimate WhatsApp connector, could hide instructions in its tool description. The agent read them, pulled the user's entire WhatsApp history, and sent it to an attacker's number as an ordinary outgoing message. End-to-end encryption did not help, because the agent was a legitimate sender.

‍

Splunk, August 2026. A critical flaw (CVSS 9.1) in the Splunk MCP Server app let an admin-role user run commands on the host. Splunk's published mitigation, in its own words: "turn off or remove the Splunk MCP Server app."

‍

A large GRC platform in our space, August 2026. This one is closer to home. One of the bigger GRC and audit platforms, a name most internal audit functions already have on the shelf, launched its MCP server in April 2026 with access "enforced at the user level." Within months it was telling customers to switch the connector off.

‍

postmark-mcp, September 2025. The first malicious MCP server confirmed in the wild impersonated a transactional email service and worked exactly as advertised. Emails were sent and delivered, and every one was silently blind-copied to an attacker. Roughly 1,500 downloads a week reached around 300 real organizations before anyone noticed. Independent researchers caught it. None of the victims' own monitoring did.

‍

mcp-remote, July 2025. CVE-2025-6514 (CVSS 9.6) hit a widely used proxy package with more than 437,000 downloads, referenced in integration guides from Cloudflare, Hugging Face and Auth0. It passed unvalidated OAuth URLs straight to the system shell. Connecting to a malicious server ran code on the developer's machine.

‍

These are not fringe vendors. Every one of them has a mature API and a security team. The pattern repeats each time. The API predates agents, and the connector inherited its assumptions.

‍

One concept is worth keeping in your back pocket: the lethal trifecta. No agent should hold all three of these at once: access to private data, exposure to untrusted content, and a way to send data out.

‍

The lethal trifecta combines private data, untrusted content and outbound access.

‍

The gap nobody has closed yet

‍

Adoption at that speed only matters to a board if oversight kept pace. It has not. Roughly 23% of organizations have a formal identity strategy for AI agents. About 14% of agents reach production with full security approval. Netwrix found 76% of organizations do not fully govern or monitor non-human identities, which is the category every one of these agents falls into.

‍

The visibility numbers are worse than the policy numbers. The Cloud Security Alliance found 82% of enterprises discovered shadow AI agents in the past year, even though 68% had reported high confidence in their own visibility beforehand. Verizon's 2026 Data Breach Investigations Report put unapproved AI tool use at 45% of the workforce, roughly triple the year before.

‍

Read the two curves together. Deployment is running at enterprise scale, while oversight is running at pilot scale. That is not a technology problem waiting on a patch. It is a governance gap with an owner, and internal audit is one of the parties accountable for naming it. The usual objection is that the technology has not settled yet, so scoping the work is premature. It is not going to settle.

‍

Why AI governance is the control that catches this

‍

Here is the part that usually gets skipped, and it is why this belongs on an audit plan rather than a security backlog. Go back through the incident list and ask what actually caught each one. The answer is almost always someone outside the victim, whether a researcher, a vendor disclosure or an independent scan. The victim's own monitoring rarely raised a hand. The traffic looked legitimate because it was legitimate. The agent was an authorized sender using an approved credential to do a permitted thing for the wrong reason. Nothing in that sentence trips a conventional alert.

‍

What does catch it is governance, and specifically five artifacts most organizations do not have yet:

‍

1. An inventory that says what exists.

‍

2. An approval gate that says who cleared it and on what basis.

‍

3. A credential map that says what each agent can reach and why it needs that much.

‍

4. A tool-call log detailed enough to reconstruct a day.

‍

5. A change-control trigger that forces re-review when a connector definition changes. A server reviewed in March and silently updated in July was never really reviewed.

‍

Every one of those is an audit artifact before it is a security control. If they do not exist, the organization is not detecting these failures. It is waiting to be told about them. Full stop.

‍

Gartner projects that through 2029, more than half of successful attacks on AI agents will exploit access control issues rather than anything exotic. That is a governance finding written in advance.

‍

What good looks like from the build side

‍

I asked Rich what separates a governed server from a wrapped API. His answer came down to four design choices, and each one maps to a test you can run.

‍

Permissions start with a person. An agent's permissions can never exceed those of its manager, the human responsible for it. They can be narrowed further, so the agent sees and does less than its manager can.

‍

Human review is built into the tool, not written into a prompt. The tool that can change a record only produces a suggestion. Nothing changes until a reviewer sees exactly what will change and approves it. "An injected instruction can, at worst, create a suggestion that someone rejects," Rich said. "The agent never holds the pen."

‍

Usage documents itself. Every tool call, its frequency, and every approved or rejected suggestion is logged without anyone having to remember to log it.

‍

Every connector passes the same gate before it reaches a user. Read the source. Scope the credential to the narrowest thing the connector actually needs to do. If you cannot say what happens to the data once it leaves the server, it does not ship. Rich's point is that none of the incidents above needed a sophisticated attacker. They needed a default nobody questioned. The gate that catches a bad default is about an hour of work, and most teams skip it because the integration guide said install and move on.

‍

Five questions before you approve a connector

‍

Put these to the vendor before anyone turns on a connector, or to your own team if you are building one.

‍

1. What can it read, and is that broader than what the person managing the agent can access?

‍

2. Can it write directly, or does it propose changes for a person to approve?

‍

3. What untrusted content does it ingest, such as tickets, email, uploaded files or web pages?

‍

4. Where can data leave? Every outbound channel counts, including the chat window.

‍

5. Can you reconstruct what it did on a given day from logs alone?

‍

Where the Standards already reach

‍

The IIA's Cybersecurity Topical Requirement has been effective since February 5, 2026, and an agent holding standing credentials to production systems sits squarely inside it. The Third-Party Topical Requirement took effect on September 15, 2026. Every connector pulled from a public registry is a vendor you never onboarded, and that requirement treats it as one whether or not anyone has inventoried it.

‍

Topical Requirements are mandatory for assurance engagements when the topic falls in scope based on the function's risk assessment, and recommended for advisory work. The Quality Assessment Manual already tests conformance through Standards 13.2 and 13.3. If you are due for an external quality assessment, this is testable now rather than next cycle. For anyone operating in Europe, EU AI Act high-risk obligations became enforceable on August 2, 2026, and gateways handling regulated data sit inside that scope.

‍

Where we landed

‍

In full transparency, we underestimated this early. The first read inside our own practice was that MCP was a developer convenience, roughly equivalent to an API integration, and that existing vendor management would cover it. That read was wrong. The cross-tenant exposure at a major work management platform in June 2025 is what changed it. Nobody attacked them. The feature shipped, an access control assumption turned out to be wrong, and roughly a thousand organizations were exposed for six weeks before it was closed. Vendor management does not catch that. Control testing does.

‍

The profession does not need a new framework here. It needs internal audit to apply the ones already in force to a technology layer that arrived faster than the audit plan did.

‍

You need two tests that are cheap enough to run this quarter and produce a workpaper you can defend.

‍

Build the inventory. List every MCP server, agent and connector in the environment with an owner, a source and a business purpose. Then reconcile that list against a scan of agent configuration files and any exposed endpoints. Expect the scan to find things the list does not. That delta is your first finding.

‍

Run the trifecta matrix. For each agent, answer three questions. What private data can it reach? What untrusted content does it read? How can data leave? Any row with three yes answers is a finding on its own. This takes an afternoon and needs no tooling.

‍

If management cannot answer the first of the five questions with a number, the other four are premature. That gap is itself the reportable condition.

‍

Want to build this instead of just reading about it?

‍

Cherry Hill Advisory and AssureSwarm are co-hosting Auditober, a free, month-long internal audit hackathon through October 2026. You build a workflow, agent skill, plugin or dashboard for a real audit phase, whether that is planning, risk assessment, fieldwork testing or reporting. Everything runs in a free sandbox loaded with mock data, so no real organizational data touches it. Setup takes as little as 30 minutes.

‍

It opens on October 8 with a free Audit Engineering CPE session hosted by Cherry Hill Advisory. We will cover connected audit systems, reusable agent skills, traceable workflows and dashboards built on MCP, with the controls above designed in from the start.

‍

You can attend the CPE session on its own or stay for the full hackathon. Every entry is shared anonymously with all participants, so everyone leaves with the whole community's work.

‍

Register for Auditober and the October 8 CPE session here

‍

The next wave of agent tooling is already on its way. The audit functions that have built something with their own hands will be the ones asking the sharpest questions when it lands.

‍

Sources

‍

Invariant Labs, WhatsApp MCP and tool poisoning disclosures: invariantlabs.ai

‍

Simon Willison, The Lethal Trifecta, June 16, 2025: simonwillison.net

‍

UpGuard, Six MCP Security Incidents Every Security Leader Should Know, July 1, 2026: upguard.com

‍

Practical DevSecOps, MCP Security Statistics 2026: practical-devsecops.com

‍

Cloud Security Alliance, MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure, May 2026

‍

OWASP GenAI Security Project, Top 10 for Agentic Applications 2026, v2.01, June 1, 2026

‍

The IIA, Topical Requirements for Internal Auditing: theiia.org

Subscribe now to join the Risk Register community: