Black Kite found critical vulnerabilities at 34.2% of AI companies assessed

A team connects an AI assistant to a repository to analyze errors and suggest fixes. The assistant receives an access token, reads code and sometimes runs commands. The project's security now also depends on how the provider stores that token and protects its own infrastructure. Good model responses tell you nothing about either.

A ZDNet article published on November 10 cites findings from a Black Kite report on AI providers. Of the 18,160 companies assessed, 34.2% had at least one unpatched critical vulnerability. For developers and founders, this is a reason to check which doors are already open to external services, from reading customer support requests to modifying code and accessing production infrastructure.

What the researchers found

The sample covers companies of various sizes, from small teams to organizations with more than a thousand employees. It includes application developers, AI implementation contractors, industry-specific services, and providers of data, computing resources and models. Companies that use AI only occasionally were excluded.

Beyond critical vulnerabilities, the researchers identified DMARC problems at 61.7% of companies and DKIM weaknesses at 37.3%. These are email authentication mechanisms. Configuration errors can make email spoofing and phishing easier: for example, an employee might receive what appears to be an internal request to reauthorize an integration.

A further 29.7% of companies were rated as highly susceptible to ransomware attacks under Black Kite's index. It is important to interpret this figure correctly: it is a risk assessment, not the proportion of organizations whose systems criminals have already encrypted. Likewise, the presence of a critical vulnerability does not, by itself, prove that it provides access to a particular customer's data.

The account also states that stolen corporate credentials were associated with 6.8% of the providers in the sample. Such a finding calls for checking whether passwords remain valid, reviewing active sessions and checking multifactor authentication. It does not amount to confirmation that all customer systems have been breached.

How a provider's problem becomes yours

Imagine a support assistant connected to a CRM. To draft a reply, it needs the text of a support request and a few fields from the customer's record. During setup, however, the team grants the service permission to export the entire database and modify records because that makes the pilot faster to launch.

If an attacker gains access to the provider, the consequences will depend on those permissions. Reading individual support requests and exporting the customer database create different scales of potential damage. It therefore helps to assess an integration through a concrete question: what could someone do if they obtained its token?

A separate analysis of MCP components mentioned by ZDNet contains 1,732 security findings. Of these, 48.8% were classified as high or critical severity, including opportunities for code and command injection. This is the proportion of findings in a separate analysis. It does not establish that 48.8% of all MCP servers or companies are vulnerable.

MCP itself helps connect AI applications to tools and business systems. The practical checks concern its implementation: who can invoke a tool, what arguments it accepts and which permissions govern the action it performs.

What to check before the next connection

Start with an inventory of AI services that have already been granted access. For each, record its owner within the team, the data it can access, the actions it is allowed to perform and a way to disable the integration quickly. This list turns a security discussion into a clear engineering task.

Next, reduce permissions to those required for the workflow. For an assistant that drafts responses, permissions to send messages, modify records or execute commands should each require separate justification. For potentially dangerous actions, human confirmation and an activity log are useful safeguards.

Ask the provider how it fixes critical vulnerabilities, protects accounts and reports incidents. Repeating the review is particularly useful when access expands: yesterday the service could read documentation; today it can write to the repository.

The report has limitations: the account provided does not allow a comparison between the risks at AI companies and conventional SaaS providers, or an assessment of a particular product's security. It does, however, provide a concrete reason to revisit permissions. Before expanding a pilot, check whether the service's access matches the task you connected it to perform.