What Changed
Your third-party ecosystem is expanding rapidly, and your intake process isn't keeping up. Each time an employee uses an unapproved AI tool, authorizes a browser extension, or connects a work account to an assistant, you're adding external service providers without procurement review, security assessment, or contract coverage.
The Model Context Protocol (MCP) exacerbates this issue. MCP standardizes how AI applications connect to tools and data sources like document repositories, codebases, email platforms, and cloud environments. This connectivity makes AI more useful but also means a single AI workflow can involve a model provider, cloud infrastructure, multiple APIs, logging services, and several connected systems simultaneously.
Bitsight TRACE researchers found about 1,000 internet-accessible MCP servers without authorization, exposing the tools they could access. This research covered remotely accessible servers using HTTP-based transports, so the actual exposure is likely larger.
Key Findings
Shadow AI creates ungoverned vendor sprawl. When employees upload documents, send prompts, or install AI-powered extensions, information may transfer to multiple external services: the model provider, cloud hosting infrastructure, plugins, connected APIs, analytics providers, and additional subprocessors. Your security team likely can't track which AI models employees are using, what information is shared, or which additional vendors are involved.
MCP turns connectors into privileged third parties. An MCP-enabled connector may have permission to read documents, search email, access source code, update records, or perform actions inside business applications. From a risk perspective, it acts like a privileged vendor. A compromised or poorly configured connector could expose data, misuse permissions, or influence the information provided to an AI system.
Fourth-party visibility becomes critical. Your vendors might be connecting AI to systems that process your data or relying on AI providers and subprocessors beyond your traditional oversight. Even if your organization has strict AI policies, your vendors might be expanding their AI ecosystems behind the scenes. You need visibility into AI products within the dependencies used by your vendors and their vendors' vendors.
Traditional risk signals miss AI exposure. Internet-facing vulnerabilities, DNS hygiene, malware infections, and breach history provide insights into security posture but don't reveal if an employee uploaded sensitive code to an unapproved AI assistant or if an AI connector has broad access to corporate documents. You're facing a visibility gap that external risk ratings and internal telemetry alone can't bridge.
What This Means for Your Team
You can't treat AI as just an internal productivity issue. Every AI interaction is a potential data transfer to an external processing environment. The vendor footprint grows whenever a user signs up for a tool, authorizes an integration, or sends corporate information through an AI interface.
The old question was: "What systems and vendors do we use?" The new question is: "Where does our data travel when employees and applications use AI?"
AI workflows are built around context. They collect information from an internal document, combine it with an employee's prompt, send it to a model, call an external tool, and return the result to another application. Risk accumulates across the entire workflow. You need visibility not only into the assets and vendors your organization owns or contracts with, but also into the external services that participate in AI-enabled workflows.
This creates several forms of supply chain exposure:
Data exposure beyond known vendors. Employees may send customer information, internal research, contracts, source code, credentials, financial data, or strategic plans to AI services that haven't been reviewed by procurement, legal, privacy, or security teams.
Transitive risk through integrations. An AI application may call other platforms or APIs to complete a task. Those services introduce their own infrastructure, data handling practices, dependencies, and security weaknesses. You may approve one AI provider without fully understanding every external service that can be reached through its integrations.
Plug-in and connector risk. A compromised, poorly configured, or malicious connector could expose data or misuse permissions. Untested instructions can be introduced through tool descriptions, retrieved documents, emails, web pages, or tool responses, potentially influencing the model's actions across connected systems.
Action Items by Priority
Immediate: Establish AI service visibility. Deploy endpoint monitoring to identify data egress to AI-related endpoints. Review browser extensions, installed applications, and authorized integrations across your environment. Build an initial inventory of AI services employees are using.
Week one: Extend vendor intake to cover AI workflows. Update your vendor intake questionnaire to ask: Do you use AI to process customer data? Which AI providers and subprocessors are involved? What permissions do AI applications have to our systems? Where is data processed or stored? Require Sub-Processor Disclosure for any vendor using AI in their service delivery.
Month one: Audit MCP and connector permissions. If your organization uses AI applications that support MCP, identify which MCP servers they connect to and what tools those servers expose. Review the permissions granted to AI applications and connectors. Ensure authorization is in place for any remotely accessible MCP servers. Revoke excessive permissions.
Quarter one: Build fourth-party visibility into AI dependencies. Extend your Fourth and Nth Party Management program to include AI products detected within vendor dependencies. Ask vendors to disclose AI providers in their supply chain. Include AI-specific requirements in your Sub-Outsourcing Clause and Right to Audit language.
Ongoing: Adapt risk assessment frameworks for AI. Traditional Criticality Classification may not capture AI-specific exposure. Consider factors such as: use of external AI services, permissions granted to AI applications, number of AI services operating across the organization, presence of high-risk or unapproved AI tools, and exposure created by connected plugins and APIs. Update your Risk Governance Framework to account for the dynamic nature of AI integrations.
