AI Plugin and Connector Security Risks in Enterprise Platforms

AI plugins and connectors don't just plug an assistant into your file system, they let it act on your behalf, with your credentials, on data it chooses to fetch and tools it chooses to call. That single shift, from human-directed integration to AI-directed integration, is what turns a productivity feature into a structural security problem. Prompt injection, data exfiltration, and supply chain compromise aren't edge cases in this model. They're the predictable result of how it's built.

Compare the two models side by side and the difference is stark. A traditional integration works because a person clicks a button, picks a file, and the software does exactly that one thing. An AI plugin works differently: user asks a question, the model interprets what that means, the model picks a tool, the model decides what parameters to pass, and the external system acts on that decision. Nobody signs off on the tool call. Nobody checks the parameters. So the question worth sitting with is: what happens if someone other than the user gets to influence how the model interprets the request? Once you can steer interpretation, you can steer which tool gets called, what arguments it gets, and what data comes back out. The user's intent stops being the thing driving the system.

Connectors scale that problem fast. ChatGPT Enterprise now ships with connectors for Box, Dropbox, GitHub, Gmail, Google Drive, HubSpot, Linear, OneDrive, Outlook, SharePoint, Teams, Notion, and custom MCP integrations, according to Varonis. Each one lets the agent pull data on its own, without a person selecting a file first. Varonis frames the resulting risk as compounding: every connector added expands the number of paths the AI can walk down without a human standing at the gate. And this sits next to a separate, quieter problem. Even where the sanctioned connectors are locked down tight, employees still copy sensitive material into consumer AI tools nobody in IT approved. Shadow AI runs parallel to the managed surface, invisible to whatever governance exists for the official stuff.

How credentialed access turns plugins into a persistent insider threat

Here's the part that doesn't get enough attention: plugins don't just read your data, they authenticate as you. They hold OAuth tokens and session credentials for every downstream system they touch. MCP servers are a clean example. Strobes.co notes that these servers often store OAuth tokens for services like Gmail directly in config files or in memory. Compromise the server, and an attacker doesn't steal one password, they inherit every token sitting there at once. That's lateral access across every connected service, handed over in a single breach.

Why does that matter more than a phished password? A stolen password usually triggers something: a login from a new location, a failed MFA prompt, an alert somewhere. A stolen OAuth token doesn't necessarily trip any of that. It's scoped, it's durable, and it operates at the API level, often below the threshold that standard authentication monitoring was built to catch.

Layer onto that what security researchers describe as the excessive agency problem. AI agents tend to run with permissions broader than any single employee would ever be granted, because the model needs broad access to function effectively across an organization's data. So the defaults get set wide. Least privilege becomes hard to enforce in this context for a simple reason: the AI needs to reach "any relevant" file to do its job the way it was designed to. The capability and the risk aren't separate variables here, they're the same variable viewed from two angles.

Inherited access controls don't save you either. If a connector inherits a user's SharePoint permissions, and that user has broad read access across a dozen departments, the AI can now traverse all of it autonomously, at machine speed, without a person choosing to open each file. The permission structure was built assuming a slower, human-paced actor.

So what should security teams actually be tracking? Which connectors are live, who turned them on, what data got touched, and the classification of every file an agent reached. Most organizations don't have a single dashboard that answers all four of those questions. That gap shows up in the numbers: According to industry research, 69% of organizations name AI-driven data leaks their top security concern for 2025, yet close to 47% report no AI-specific security controls at all. Read those two figures together and the picture is uncomfortable. Most companies have already turned on credentialed AI access and simply haven't built anything purpose-made to watch it.

Model Context Protocol has become the connective tissue, and the widest open door

MCP is fast becoming the standard way models talk to enterprise tools, external APIs, and multi-step agent workflows. Once a model has it, the model can discover which tools exist, call functions, hold context across a conversation, and chain several actions into one workflow. That's the engine underneath agentic AI as it runs in production today, not a lab demo.

Microsoft folding MCP support into Copilot Studio and Azure AI Foundry pushed enterprise adoption ahead faster than expected, per eSentire. MCP stopped being a protocol enthusiasts talked about and became something companies depend on by default.

Scale is where this gets uncomfortable. Check Point's 2026 Cybersecurity Report scanned 10,000 MCP servers and found AI security weaknesses in 40% of them. That's not a handful of misconfigured test instances, that's four in ten servers carrying some kind of exposure. Strobes.co adds a detail that makes the picture worse: as of mid-2025, there were no dedicated security tools built for MCP specifically, some vendors were waving off security reports as "not vulnerabilities," and new servers kept going up daily carrying basic, avoidable flaws.

The NSA eventually said the quiet part out loud. On May 20, 2026, it published "Model Context Protocol: Security Design Considerations for AI-Driven Automation," warning that MCP adoption has outrun the security work needed to make it safe. Its core finding is worth sitting with: authentication, authorization, input validation, all the standard cyber hygiene, remain necessary but aren't sufficient anymore. MCP introduces something new, dynamic tool invocation, implicit trust between systems, and shared context that established defenses were never built to watch.

That last phrase, implicit trust, is the thread that ties the whole architecture together. An MCP client trusts the server it connects to, and that trust doesn't get re-checked continuously. It's set once and left alone. Every attack in the next section walks straight through that open door.

The four attack classes that exploit the plugin trust model

Prompt injection comes in two flavors. Direct injection is an attacker typing something into a chat box that overrides the system's instructions. Indirect injection is subtler and more dangerous: instructions buried inside a document, an email, a support ticket, or a web page that the model later pulls into its context window. The user never sees the payload, because the user never opened that file, the AI did. Indirect prompt injection has been identified as generative AI's biggest security flaw, and OWASP's 2025 Top 10 for LLM Applications puts it at the top of the list, per arXiv. Plugin access is what makes this dangerous rather than just annoying: if the model can call APIs, run code, or hit internal URLs using credentials it already holds, a successful injection doesn't just produce bad text, it produces a real action in a real system.

Tool poisoning hides adversarial instructions inside MCP tool descriptions, parameter schemas, or response bodies, content the agent treats as trusted operational context rather than as something to scrutinize. The Cloud Security Alliance points out there's no built-in MCP mechanism to catch this. A documented proof-of-concept from April 2025 showed the mechanics clearly: a malicious trivia-game MCP server embedded hidden instructions in its own tool description, targeting a separate, legitimate WhatsApp MCP server running in the same agent session. The agent pulled WhatsApp message history and routed it outbound through the trusted server, looking like ordinary traffic the whole way. Transport encryption didn't help at all, because the theft happened above that layer, inside the agent's reasoning, not on the wire. Tests across more than 45 real-world MCP servers put the attack success rate above 60%, according to CSA.

Rug pull attacks exploit a timing gap. A user approves a server at install time, then later, silently, the server changes its own tool description to add malicious instructions. CSA notes the MCP spec has no way to track that a tool definition changed, and no requirement to re-approve it if it does. Approval happens once, not continuously, which means the exploit window is everything between install day and whenever, if ever, a user happens to look again.

Supply chain compromise rounds out the list. A malicious package, a tampered model, or an untrusted plugin can steal data or introduce hidden behavior while looking completely legitimate, sometimes staying deeply embedded for a long stretch before anyone notices, per Mend.io. The damage ranges across data theft, unauthorized access, model manipulation, poisoned outputs, and backdoors nobody asked for. And the ecosystem's growth rate doesn't help: new MCP servers appear daily, vetting is minimal, and vetting is minimal and new servers carry basic, avoidable flaws.

Notice the common thread running through the MCP-specific attacks described above, tool poisoning and rug pulls in particular. CSA traces them to one structural cause: clients inherit trust from the servers they connect to, and nothing re-verifies that trust once it's granted.

What EchoLeak and CVE-2025-53773 show about production AI systems

Two vulnerabilities from 2025 turn the theory into something concrete.

EchoLeak, tracked as CVE-2025-32711, hit Microsoft 365 Copilot. Aim Security researchers disclosed it in June 2025, and Microsoft rated it 9.3 out of 10 on the CVSS scale, critical. It's a zero-click indirect prompt injection: an attacker hides instructions inside a crafted email, Copilot pulls that email into its retrieval context, and it carries out the hidden instructions without the user clicking anything at all. What could it reach? Chat logs, OneDrive files, SharePoint content, Teams messages, all routed out to an attacker-controlled server. The attack chain, documented in arXiv, is a genuine study in layered evasion: it slipped past Microsoft's cross-prompt injection classifier, dodged link redaction using reference-style Markdown formatting, exploited images the system auto-fetches, and abused a Teams proxy the content security policy happened to allow. Four separate bypasses, chained together, to cross every trust boundary the LLM had. Sentra calls it the first documented case of prompt injection weaponized for actual data theft inside a production AI system, and the pattern it reveals applies to any assistant wired into multiple internal data sources, not just this one. Microsoft patched it server-side in June 2025. No customer action was required, and no exploitation in the wild has been confirmed.

CVE-2025-53773 hit GitHub Copilot and VS Code, a critical flaw enabling remote code execution through prompt injection, working across Windows, macOS, and Linux alike. The root cause sits in improper handling of special elements during command execution (CWE-77), which let Copilot rewrite the workspace's own configuration file, .vscode/settings.json. Once an attacker can touch that file, they can flip on what's known as "YOLO mode," stripping out the human confirmation step Copilot normally requires before running a command. At that point the assistant isn't executing your commands anymore, it's executing whoever poisoned that config file's commands.

Line those two up and the pattern is unmistakable. Both involve AI systems with plugin or connector access to internal data. Both were triggered through content the AI fetched on its own, not through anything the user typed. Both achieved privilege escalation by abusing the AI's own trust relationships, not by exploiting some flaw in the servers underneath. And in both cases, the fix came entirely from the vendor's side. While these bugs were live, organizations had no independent way to detect or block them using the security tooling already sitting on their network. That's the evidence behind the argument that follows: generic governance frameworks were never built to watch the layer where these attacks actually happen.

Why the security controls enterprises already have don't see these attacks

Traditional security monitoring watches infrastructure: network traffic, endpoint behavior, login logs, API call counts. None of that tells you what the AI agent decided to do once it read something into its context window. That decision happens somewhere between input and tool call, inside the model's reasoning, a layer that SIEM, DLP, and CASB tools were never built to look inside.

Only 18% of enterprises have a dedicated council responsible for AI governance, according to Wiz. That's not a tooling gap, that's an organizational one: most companies don't even have a group whose job is to own this risk, let alone the instruments to monitor it.

Compliance frameworks like SOC 2 and ISO 27001 cover data handling and access control reasonably well. But what do they say about dynamic tool invocation? About implicit trust in an MCP server? About a tool description that changed silently between two sessions? Nothing. Those checklists were written for a slower, more static kind of system, and MCP doesn't behave like one. The NSA's May 2026 guidance said as much directly, per Intelligence Community News: authentication and input validation still matter, but they don't reach MCP's newer risks.

Stack up the actual blind spots and they're layered, not singular. Platforms like PromptArmor exist specifically to track these third-party AI vendor risks continuously. Security teams often can't say which connectors are enabled or who turned them on. They can't say what data got pulled in a given agent session. They can't tell whether a tool's description changed since it was approved, the exact rug pull surface described above. And they usually can't say what third-party MCP servers an agent is even calling, or what those servers currently claim they can do. Shadow AI sits on top of all of it: even a tightly governed connector rollout runs alongside employees pasting sensitive data into consumer tools that no policy touches.

None of this gets fixed by doing more of what already exists, just harder. It's a category problem. The attack surface is AI-specific, so the instrumentation watching it has to be AI-specific too.

The security controls that match the actual attack surface

Start with an inventory that's actually current, not a spreadsheet updated once a quarter. Every plugin, every connector, every MCP server in use across every vendor needs to show up somewhere, including the ones nobody officially sanctioned. That means tracking who turned each connector on, when, what permission scope it was granted, and what data classifications it can reach. You can't govern a system you can't see, and right now most security teams are missing at least a third of the picture.

Least privilege has to move down to the connector level, not stay a policy statement in a document nobody rereads. Scope each connector to the narrowest set of data sources its job actually requires, and resist the pull toward broad defaults just because broad defaults get adoption numbers up faster. Varonis makes a useful distinction here: overly permissive grants should trigger an actual review, with a person deciding whether to narrow it, not just get logged somewhere for later.

Runtime monitoring is where most of the real defense has to live. Log what tools an agent actually calls, with what parameters, and what data comes back, not just whether the API request succeeded at the network layer. Watch for behavior that doesn't fit the pattern: an agent suddenly calling tools it's never called before, pulling data outside its normal scope, or making an outbound connection that has nothing to do with its stated job. This is the layer that, in principle, could have caught the EchoLeak exfiltration path before anything left the tenant.

Tool definitions need integrity checks too. Track what an MCP tool's description says across sessions, and flag it the moment it changes. That's the direct countermeasure to rug pull attacks, which exist entirely because the MCP spec has no mechanism for this today. Pair it with a re-approval step: if a tool's definition changes, a human signs off again, rather than the system assuming yesterday's approval still applies.

And before connecting any new MCP server or plugin, it's worth actually reading what it claims to do, checking the tool descriptions and parameter schemas by hand rather than trusting the marketing copy. Given how many servers ship daily with no central review, that manual step, tedious as it is, remains one of the few checks standing between an enterprise and a poisoned tool nobody bothered to look at closely enough.