Who Does Your AI Plugin Work For? How to Audit MCPs and Extensions

Estimated reading time: 10 minutes.

You install an extension, connect an MCP server, and within minutes the AI can search documents, open tasks, and work on your project. The demonstration works. The question that tends to arrive late is less exciting: what data can this tool access, and where can that data go?

In my integration work at Oombe, one concern follows every feature: what that access allows someone to do in the connected account. AI agents add more paths to consider. A feature that appears to help write code may participate in a sequence involving files, credentials, external services, and models from different providers.

The “install” button is small. The list of decisions hiding behind it can be surprisingly long.

Fortunately, we can organize this assessment without turning every installation into a detective movie. The starting point is to distinguish different problems, because each requires its own evidence and controls.

Three problems that deserve different names

Malicious software is designed to perform an unauthorized action. Imagine a fictional tool that promises to summarize support tickets but also sends copies to an external address. The useful operation packages the hidden one.

Vulnerable software may have a legitimate purpose and an exploitable flaw. An authorization error, for example, could let one person access another person’s information. Fixing that flaw and understanding the exposure requires different work from investigating malicious intent.

A contractual gap occurs when the documentation does not explain the actual processing sufficiently. A vendor may use additional services without describing them clearly. That calls for clarification and assessment, but does not automatically establish a data breach.

These situations can overlap. Calling all of them “MCP malware,” however, makes diagnosis harder. It also invites an overly comfortable conclusion: replace the tool and assume governance is sorted.

OWASP LLM03:2025 includes third-party dependencies, components, and models in its discussion of the AI supply chain. This framework helps us view the application as a set of relationships with distributed responsibilities.[1]

MCP connects tools; trust still needs to be built

An agent’s appeal is its ability to act on systems. That also requires asking who defined a tool, what instructions it presents to the model, and which actions the environment actually permits.

In April 2025, Invariant Labs demonstrated tool poisoning attacks: malicious instructions embedded in tool descriptions could influence an agent. The demonstration documents a risk category; it does not establish that every current client has the same vulnerability.[2]

Think of a reception desk receiving notes from suppliers. A note may provide a delivery time. It should not authorize changes to who can open the safe. An AI system needs that separation in controls outside the model as well.

The MCP draft security documentation addresses authorization, isolation, and token audience validation, and prohibits improper token passthrough. It also distinguishes risks in certain proxy architectures from the stdio transport itself.[3]

The practical implication is straightforward: a warning in a prompt does not replace system-enforced permissions. If a tool only needs to retrieve information, the design should restrict what it can retrieve and prevent unnecessary changes.

Does the contract tell the same story as the architecture?

A DataGrail study published in 2026 reported that 63.6% of vendors assessed in the study did not disclose third-party AI subprocessors in their legal documentation. The company describes cross-checking contracts against evidence including integrations, GitHub activity, and commercial websites.[4]

The figure deserves attention, but its meaning needs to stay intact. It identifies a transparency gap in a commercial vendor’s research. It does not mean that 63.6% of tools leaked data, nor does it establish the destination of every request they processed.

To assess a particular product, I would start with direct questions: which companies receive data, under what circumstances, for how long, under what usage conditions, and how changes will be communicated.

One detail belongs in that conversation: fallback. If the primary model is unavailable, may the service call another one? That alternative needs to remain within the approved policy. Define permitted providers, authorized data categories, and the behavior when no acceptable option is available.

This connects with the differences between a Privacy Policy and Terms of Use. Clear documentation helps establish expectations; the implementation needs to support those expectations.

What Bumblebee can help you discover

Perplexity’s Bumblebee collects local metadata about packages, extensions, and certain tool configurations on macOS and Linux. It operates in read-only mode and compares its inventory against catalogs of known exposures. Its scope does not amount to a universal malware detector or a contractual audit.[5]

That is useful for a specific question: “Do we have the component or version named in this advisory?” An organized inventory reduces the effort required to answer it machine by machine.

Other questions remain: did the tool send data? Was the destination authorized? Did the credential allow too much access? Did the contract describe the processing? Each requires additional evidence.

Since I use Windows day to day, I would also check coverage before turning a tool into an operational recommendation. A procedure presented for Linux should not be sold as a complete audit of a Windows workstation. The goal is to map the real environment, including areas the scanner does not cover.

An audit that begins with answerable questions

The first deliverable can be a simple table. For each tool, record its owner, origin, version, purpose, granted access, expected destinations, and last review date. Then work through six questions.

1. Who maintains this software? Check the path between the official website, the repository, and the installed package. Similar names help you find things; by themselves, they do not establish provenance. Record how identity was verified and who follows future updates.

2. Which resources does it actually need? Compare the task with the permissions. Does a documentation reader need write access to the entire project? Does it need the credentials used in production? Every extra capability deserves an operational justification.

3. What data crosses the integration? Trace a request from beginning to end. Include attachments, code excerpts, and returned results. Consider supporting components too: error reporting, support, and observability may participate in the flow.

4. Which destinations are permitted? Document providers, services, and fallback conditions. Wherever feasible, enforce that policy in the execution environment. An instruction saying “use only the approved provider” leaves a question unanswered: what prevents a different call?

5. How do changes arrive? Define who reviews package updates, tool changes, and permission expansion. Initial approval loses some value if later changes arrive with no follow-up.

6. How do you stop and recover? Know how to revoke the credential, disable the integration, preserve necessary evidence, and identify affected operations. The procedure must fit the team’s reality. A plan that is impossible to execute at three in the afternoon is unlikely to get easier at three in the morning.

These answers create a verifiable picture. They also reveal priorities: first address the access and data flows with the greatest impact, then investigate the remaining areas.

An example for people working with marketplaces

Imagine a fictional assistant for an e-commerce operation. It reads customer questions, retrieves order information, and prepares a reply. The proposition makes sense. Now put all those functions behind a single credential that can also change listings and account settings.

The architectural problem appears before any attack: the granted capability exceeds the stated task.

An alternative would separate order lookup, knowledge-base access, and reply preparation. Sending the reply would have its own rule. Commercial changes would belong to another workflow with specific permissions and validation.

If the assistant encounters unusual text in a message, this separation reduces the set of available actions. The question expands from “Will the model understand correctly?” to “What consequence does the system allow if it gets the interpretation wrong?”

This is a hypothetical example, not a report of an incident at Oombe. Integration experience helps formulate the right question: which capabilities are we delegating, to whom, and under what conditions?

A small test that produces useful evidence

Before bringing a sensitive environment into the lab, build a demonstration project with fictional documents and credentials. Define two tools: one can read an example folder; the other accesses a test API with a limited scope.

Prepare expected tasks and out-of-scope situations. Check whether the agent can request an improper action, whether the environment blocks it, and whether the record explains what happened. Also simulate primary-provider unavailability: does fallback respect the permitted list?

Record the outcome carefully: requested attempt, authorization decision, actual execution, and destination. An action suggested by a model and an action executed by a system have different consequences.

This exercise does not certify complete security. It provides evidence for a defined set of requirements and helps locate controls that existed only in conversation.

The service worth delivering

For anyone considering consulting, there is a concrete deliverable here: an inventory, a data-flow map, a permission matrix, a review of contractual conditions, and a prioritized remediation plan. Legal review may require specialized participation; the technical work needs to show what the architecture actually does.

The value lies in reducing uncertainty about a particular operation. Promising that a scanner “guarantees security” creates an expectation it cannot support.

In the discussion of privacy and power over data, the practical question remains who can do what. Agents expand the usefulness of integrations. Our responsibility is to make the boundaries grow alongside that usefulness.

Before installing the next amazing tool, set aside five minutes for one question: if this tool acts outside expectations, can the environment stop it? The answer often says more about a project’s maturity than the beauty of its demonstration.

Sources and further reading

1. OWASP — LLM03:2025 Supply Chain.
2. Invariant Labs — MCP Security Notification: Tool Poisoning Attacks, April 2025.
3. Model Context Protocol — Security Best Practices, draft documentation.
4. DataGrail — discussion of the Privacy & AI Trends Report 2026, June 2026.
5. Perplexity — official Bumblebee repository.

Sources consulted on October 26, 2026. Features, coverage, and security recommendations should be checked against the version being used.