Layer 3: The integrations
MCP: The Connector That Turns an AI Tool Into an Access Path
AI applications are increasingly moving beyond generating answers to interacting directly with business systems. They can retrieve documents, query databases, update records, and perform actions through connected tools.
The Model Context Protocol (MCP), introduced in late 2024, provides a standardized way for AI applications to connect to external tools and data sources. An MCP server can expose functions that allow an AI application to interact with services such as databases, file repositories, development environments, or business platforms.
This introduces a different dimension of cybersecurity risk. When an AI application can act on external systems, the security of those connections becomes just as important as the security of the AI application itself.
A vulnerable MCP component may expose information or functionality available through its connections. If it operates with powerful permissions, the consequences can extend beyond the AI application to the business systems it interacts with.
Research into the rapidly growing MCP ecosystem has revealed significant security concerns.
A 2025 academic study examined 8,060 MCP server projects across six marketplaces and found that 11.2% contained code potentially invoking security-sensitive APIs. The researchers also identified uneven maintenance practices and widespread reuse of software dependencies.
By May 2026, Censys had identified more than 21,000 internet-accessible MCP server instances. A separate study published in July 2026 dynamically audited 414 internet-facing MCP servers and found that 91.8% lacked OAuth authentication.
These findings illustrate how quickly AI-connected infrastructure is expanding and why authentication, access controls, and the security of connected tools deserve attention.
The analysis covers publicly discoverable MCP-related software and services, including published repositories, packages, and hosted components. These entries are associated with company domains but do not necessarily represent live production deployments. Private MCP deployments inside company environments are outside the scope of this analysis.
What the scan results show
Black Kite's separate analysis covered 1,732 security findings across 305 publicly discoverable MCP server entries attributed to 179 AI companies. Of those findings, 48.8% were rated High or Critical. Critical findings accounted for 4.4%, High for 44.3%, Medium for 47.4%, and Low for 3.8%.
Among Critical findings, 51.9% involved code injection, 35.1% command injection, and 13.0% data exfiltration. Together, code and command injection represented 87.0% of Critical findings.
Code and command injection vulnerabilities may allow attackers to execute unauthorized instructions or commands, while data exfiltration weaknesses may expose information accessible through the affected component.
For organizations using AI applications connected to internal systems, these findings highlight the importance of securing the software that enables those connections. When a vulnerable component has access to sensitive data, customer environments, or operational systems, successful exploitation could have consequences beyond the AI application itself.
Separately, Black Kite's platform identified publicly accessible MCP servers at four AI companies. This measures publicly reachable services and is distinct from the vulnerability analysis of MCP-related software.
MCP Findings in the Forbes AI 50
Publicly discoverable MCP-related entries were associated with 34% of the Forbes AI 50 company domains. Entries associated with 32% of the cohort had at least one vulnerability finding.
The latest scans of these entries contained 201 findings. Within this separate MCP analysis, 45.8% of the 201 findings were rated High and 0.5% Critical. Medium-severity findings accounted for roughly half, and Low-severity findings for 5.0%. The Critical finding involved code injection.
These results extend the Forbes AI 50 assessment beyond traditional internet-facing infrastructure and into the software components that can connect AI applications to external tools and business data. The potential impact of a vulnerability depends on how the affected component is deployed and what systems it can access.
These results are reported separately from the broader MCP analysis.
Case Study
Salesloft Drift: An AI chat tool with standing access to Salesforce
The Salesloft Drift incident predates broad MCP adoption, but it shows what standing integration access can do once it is compromised.
Drift, an AI chat tool that Salesloft offered to sales and marketing teams, connected to its customers’ Salesforce environments through OAuth tokens, the standing credentials that let an integration act on a customer’s data without a new login.
Between August 8 and 18, 2025, a threat actor used stolen Drift tokens to export data from the Salesforce environments of companies that had integrated the tool. According to Black Kite’s analysis of the incident, the attackers had accessed Salesloft’s GitHub account between March and June 2025 and reached Drift’s cloud environment, where they obtained the tokens. In the exported data they searched for further credentials, including Amazon Web Services access keys, passwords and Snowflake-related tokens.
The campaign reached far beyond one vendor. Google estimated that more than 700 companies may have been attacked, and Cloudflare, Zscaler and Palo Alto Networks were among those that confirmed exposure. Salesloft and Salesforce revoked all active Drift tokens on August 20, and Salesforce removed the app from its marketplace while the investigation ran.
The Salesloft Drift incident illustrates a challenge for third-party cyber risk teams: organizations can grant integration access to business systems without fully understanding how that access could be misused if the integration is compromised.
When evaluating an AI supplier, customers need to understand which systems the product connects to, what information it can access, what actions it can perform, and how quickly those permissions can be restricted or revoked.
1. The supplier
Attackers reach Salesloft’s GitHub and Drift’s cloud environment.
March to June 2025.
2. The integration
Drift’s OAuth tokens stolen. Standing access to customer Salesforce data.
3. The customer systems
Data exported from Salesforce environments. More than 700 companies possibly affected.
August 8 to 18. Tokens revoked August 20.
No external scan of Salesloft would have shown a customer that Drift held standing access to its Salesforce data.
Next: Across all three layers the pattern is the same: the risk sits with a supplier you chose, in components you did not, behind access you granted.
Six actions address each layer.