The Invisible Expansion of the Attack Surface: Shadow AI, MCP, and Third-Party Risk

AI adoption is moving faster than most of us anticipated and, more importantly, faster than most organizations can govern it. Organizations are implementing the use of AI-enabled applications, browser extensions, coding assistants, and automated agents to enable employees to work faster. In many cases, these tools are adopted without security review, procurement approval, or a clear understanding of where organizational data is being sent. This is often described as Shadow AI, but the term can make the problem sound like an internal productivity or policy issue. Unfortunately, the risk extends way beyond that. 

Every unapproved AI tool can introduce a new external service provider, integration, data processor, or dependency into the organization’s environment. In practice, Shadow AI can expand an organization’s third-party ecosystem in real time, often happening quietly in the background and making it difficult for security teams to track.

The rise of the Model Context Protocol, or MCP, adds another layer. MCP makes it easier for AI applications to connect with tools and data sources such as document repositories, codebases, email platforms, collaboration tools, and business applications. That connectivity makes AI far more useful. On the flip side, depending on how it is implemented and secured, it can create new pathways through which sensitive information, permissions, and third-party risk can move. Weak authorization, excessive permissions, and untrusted content can also give threat actors more avenues to exploit. The attack surface now extends beyond traditional assets and known vendors into an ever-expanding network of AI models, connectors, plugins, APIs, and external services.

Shadow AI is a third-party risk problem

Shadow AI is usually defined as the use of AI tools that have not been approved or managed by an organization. While this is true, it doesn't show the whole picture. You can secure your own AI system, limit permissions, and set up heavy guardrails, but what about your vendors? Vendors may connect AI to systems that process your data, or rely on AI providers and subprocessors that are beyond your traditional line of sight. Even when your organization has strict AI policies, your vendors may be expanding their own AI ecosystems behind the scenes. 

When an employee pastes information into an AI tool, uploads a document, connects a work account, or installs an AI-powered extension, information may be transferred to one or more external services. Depending on the tool and its configuration, that ecosystem could include:

• The model or application provider
• Cloud hosting and processing infrastructure
• Plugins and browser extensions
• Connected APIs and business applications
• Logging, analytics, or monitoring providers
• Additional subprocessors used by the service

This is similar to the Shadow IT problem organizations have managed for years, but AI adoption is moving significantly faster. AI is now at our fingertips. It only takes seconds to log on and get access to an AI service. 

AI is an incredible tool that enables us to move at scale, but it also presents some security risks. That speed and accessibility are part of what makes AI so difficult to govern. The vendor footprint is expanding every time a user signs up for a tool, authorizes an integration, or sends corporate information through an AI interface. The same issue extends into the supply chain. The risk extends into fourth-parties. With fourth-party visibility, organizations can begin to identify AI products detected within the dependencies used by their vendors and their vendors’ vendors.  

The internal frontier meets the external attack surface

AI tools are blurring the line between internal activity and external services. A user might feel like they are interacting with a single assistant inside a familiar interface, but behind that interface the application may be communicating with a model provider, retrieving information from internal platforms, calling external APIs, or passing data through several connected services.

This demands change in how organizations think about exposure.

• 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 and typically require more information in order to complete a task. Often AI systems 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. This makes it much harder to assess where the risk is accumulating across the workflow. Security teams need visibility not only into the assets and vendors an organization owns or contracts with, but also into the external services that participate in AI-enabled workflows.

MCP can multiply the risk

MCP is an open standard designed to help AI applications connect with external tools and data sources in a consistent way. MCP servers can expose tools, resources, and prompts to an AI application. While it does not independently determine how an AI system builds or uses context, it can make it easier for an AI application to access information and perform actions across connected systems.

Those connections might include:

• Internal documents and knowledge bases
• Source code repositories
• Email and calendar platforms
• Collaboration tools such as Slack
• Customer relationship management systems
• Cloud environments
• Third-party APIs
• Development and security tools

This greatly expands the capabilities and footprint of an AI system. It allows an AI system to move quickly, while also expanding the number of systems, permissions, and vendors involved in a single workflow. From a risk perspective, an MCP-enabled environment is beginning to resemble a dynamic supply chain. Organizations are not only trusting the AI model, but they may also be trusting the application hosting the model, every MCP server it connects to, the tools those servers expose, the credentials used to access them, and any additional services called during the process as well. The risk extends across the entire context and integration graph.

This is not theoretical. Bitsight TRACE researchers identified roughly 1,000 internet-accessible MCP servers with no authorization in place and were able to retrieve the tools those servers exposed. That should make all of us pause. The research covered remotely accessible servers using HTTP-based transports, meaning it did not account for local or internal MCP deployments.

How AI creates new forms of supply chain exposure

There are several ways Shadow AI and connected AI systems can introduce third-party and supply chain risk.

Data exposure beyond known vendors

Employees may send sensitive information to AI services that have never been reviewed by procurement, legal, privacy, or security teams. This could include customer information, internal research, contracts, source code, credentials, financial data, strategic plans, or other confidential material. The organization may have little visibility into how that information is processed, retained, logged, or shared with subprocessors.

Transitive risk through integrations

An AI application may call other platforms or APIs to complete a task. Those services may introduce their own infrastructure, data handling practices, dependencies, and security weaknesses. This creates transitive risk. The organization may approve one AI provider without fully understanding every external service that can be reached through its integrations.

Plug-in and connector risk

An AI connector may have permission to read documents, search email, access code, update records, or perform actions inside business applications. That makes the connector more than a simple feature. From a security perspective, it behaves like a privileged third party. A compromised, poorly configured, or malicious connector could expose data, misuse permissions, or influence the information provided to an AI system. 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. 

Shadow vendor sprawl

Security teams may not know:

• Which AI models and applications employees are using
• What information is being shared
• Which integrations have been authorized
• Where the data is processed or stored
• What permissions each tool has received
• Which additional vendors or APIs are involved
• Which AI products and dependencies their vendors and fourth parties rely on 

Without that visibility, organizations cannot accurately measure the size or risk of their AI ecosystem.

What this means for security ratings and risk quantification

Traditional external risk signals remain important. Internet-facing vulnerabilities, exposed services, insecure configurations, DNS hygiene, malware infections, and breach history can all provide meaningful evidence about an organization’s security posture. However, those signals alone were not designed to capture every risk created by AI adoption. They may not show that an employee uploaded sensitive code to an unapproved AI assistant or that an AI connector has broad access to corporate documents. Now, security professionals are faced with an emerging visibility gap.

Over time, organizations may need a combination of internal telemetry, governance data, and external risk and threat intelligence to evaluate factors such as:

• Use of external AI services
• Data egress to AI-related endpoints
• The security posture of AI vendors
• The permissions granted to AI applications and connectors
• The number of AI services operating across the organization
• The presence of high-risk or unapproved AI tools
• Exposure created by connected plugins, APIs, and MCP servers
• AI products and concentrated dependencies across the extended supply chain

For cyber risk intelligence providers, this represents an opportunity to expand how AI ecosystem exposure is discovered, measured, and communicated. Security ratings may eventually need to account not only for the security of an organization’s traditional infrastructure, but also for the external AI services that interact with its users, systems, and data.

This is a forward-looking opportunity. Security ratings and outside-in-intelligence are not replacements for the internal tools needed to inspect prompts, monitor data flows, manage identities, and enforce AI access policies. The real opportunity is to connect these internal signals with evidence about the external vendors and infrastructure involved. 

What this risk looks like in practice

Consider a few common scenarios:

1. An employee pastes confidential customer information into a public AI tool to summarize it. The information leaves the organization and enters an external processing environment that security teams may not have reviewed.
2. A department adopts an AI assistant with access to Google Drive, Slack, and a CRM platform. The tool can now retrieve information from several internal systems and may call additional third-party services to complete requests.
3. A company relies on an AI vendor with weak security controls or exposed infrastructure. Even if the company’s own environment is well protected, the vendor may create an indirect path to sensitive information.
4. An AI plugin or MCP server is compromised and begins returning manipulated or malicious content. That content is then included in the model’s context, potentially influencing outputs or actions across connected workflows.

None of these scenarios fit neatly into traditional asset inventories or annual vendor questionnaires. They develop through day-to-day employee behavior, integrations, and automated data flows.

Why existing third-party risk programs fall short

Shadow AI can bypass the traditional third party processes. Employees can begin using an AI service before the organization knows the vendor exists or a user can grant a connector access to corporate data without going through a traditional onboarding process. New tools and integrations are appearing far faster than a security team can manually review them.

Even approved vendors can change after onboarding, in this day and age, everything is evolving rapidly. Maybe they add AI features or introduce new integrations, change suppressors, or begin replying on additional AI products without triggering a full reassessment. 

Organizations therefore need a more continuous approach to identifying and assessing:

• AI tools in use across the business
• External endpoints receiving corporate data
• Model and application providers
• Plug-ins, connectors, and MCP servers
• Changes in permissions and integrations
• The security posture of the vendors involved
• New exposure paths created by AI-enabled workflows
• AI and fourth-party dependencies used throughout the vendor ecosystem. 

How Bitsight can support the next phase of AI risk management

AI risk will require organizations to bring together capabilities that are often managed separately today, including attack surface management, third-party risk management, threat intelligence, data security, identity governance, and network monitoring.

Discover

Organizations first need to identify AI-related services and infrastructure that may introduce external or supply chain exposure.

Bitsight Security Posture Management can uncover hidden internet-facing assets and exposures across an organization’s infrastructure, subsidiaries, cloud environments, and third parties. Bitsight Continuous Monitoring can also surface AI products detected within the dependencies used by vendors and their vendors.

Quantify

Once identified, AI vendors and integrations can be evaluated in the context of their broader security posture. Bitsight can assess the externally observable security posture of AI vendors and other dependencies, surface relevant vulnerabilities and threat activity, track performance over time, and compare organizations with their peers. 

Monitor

Organizations need continuous visibility into newly identified dependencies, changes in external infrastructure, and shifts in vendor security posture. Bitsight Continuous Monitoring tracks changes in third-party cybersecurity performance, vulnerabilities, active targeting, dark web activity, and extended supplier relationships. This can help teams identify when an AI vendor or dependency becomes riskier after onboarding. 

Control

Security and governance teams can use this intelligence to inform policy and enforcement decisions. Bitsight data and workflows can help organizations determine which vendors require additional due diligence, remediation, contractual controls, restricted use, or removal from an approved vendor list.

That may include:

• Requiring additional assessments for high-risk AI vendors
• Restricting integrations with vendors that have weak external security
• Limiting the data or systems available to higher-risk services
• Reviewing vendor permissions and fourth-party dependencies
• Reassessing providers when their security posture changes
• Maintaining an approved list of AI vendors

Bitsight Vendor Risk Management supports vendor onboarding, assessments, continuous monitoring, and response across the third-party lifecycle.

Educate

Employees also need a clearer way to understand the risk. Using an AI tool is not only a software decision. In many cases, it is a data-sharing decision involving one or more third parties.

Bitsight data, benchmarking, and reporting can help security, procurement, legal, risk, and executive teams communicate why a particular AI vendor or dependency presents concern. Employee training, acceptable-use policies, and enforcement still need to be owned by the organization. Framing AI use in those terms can help employees make better choices about what information they share and which tools they trust.

Where additional support is needed, Bitsight Professional Services can augment security and third-party risk teams through managed assessments, vendor discovery analysis, threat intelligence assessments, monitoring, and reporting.

AI risk will become part of the external risk picture

AI is becoming embedded across business applications, vendor ecosystems, development workflows, and security operations. As that happens, AI exposure will become part of the broader attack surface. Security programs will need to account for external AI services, context integrity, integration risk, and the growing number of vendors participating in AI-enabled workflows. Threat models will also need to consider not only the model itself, but the tools, data sources, permissions, and infrastructure surrounding it. Security ratings and risk quantification will likely evolve alongside these changes.

The next generation of external risk visibility may need to answer questions such as:

• Which AI services are interacting with the organization?
• Which vendors have access to sensitive information?
• What external systems are connected to AI workflows?
• How secure are the providers involved?
• Where can risk spread through plugins, APIs, and MCP connections?
• How does the organization’s AI exposure compare with its peers?
• Which AI products are embedded across our vendor and fourth-party ecosystem? 

Organizations that cannot answer these questions may underestimate the size of their external risk footprint.

The next frontier of attack surface visibility

Shadow AI represents the real-time expansion of an organization’s vendor and data-sharing ecosystem. Employees can introduce new external dependencies almost instantly, while AI integrations can connect those services to internal data and business systems.

MCP can accelerate that connectivity by giving AI applications a standardized way to interact with external tools and data sources. That creates valuable capabilities, but it also introduces a new layer of context-driven and supply chain risk. The next frontier of security visibility is not limited to identifying assets or maintaining a list of vendors.

Organizations also need to understand how their data moves through AI systems, which external services participate in those workflows, and how risk can travel across the wider AI ecosystem.