Enterprises Are Blind to Two-Thirds of Their AI Attack Surface, Snyk Warns

Snyk has put a stark number behind enterprise AI risk: nearly two-thirds of the relevant attack surface can sit outside security teams’ direct view. The warning, surfaced through Google News, focuses on agents, plugins, datasets, and data pipelines connected across daily work. These components multiply as companies move AI experiments into production.

The number comes from Snyk, not an independent audit of the entire enterprise market. Its supporting analysis uses anonymized information from more than 500 enterprise environments associated with Snyk Evo. That distinction matters. The data offers a view into participating environments, while the broader claim still requires validation across other platforms and industries.

Even with that caveat, Snyk is describing a problem that reaches beyond one vendor’s telemetry. Cloud Security Alliance research found that 68% of surveyed organizations could not clearly distinguish AI-agent actions from human activity. OWASP has separately documented prompt injection, excessive permissions, and uncontrolled agency as material application risks.

The central conflict is therefore not AI adoption versus resistance. It is rapid, decentralized deployment versus security systems built around known applications, human identities, and stable inventories. Enterprises are authorizing more software to reason and act, while losing confidence about what is connected to their data.

That gap pressures security teams, but it also reaches developers, platform engineers, procurement leaders, and business owners. Every group can introduce an AI dependency. Few organizations have one system capable of mapping the resulting chain from model to plugin, identity, dataset, API, and production action.

Why the Snyk Warning Reached Google News

Snyk’s most important claim is not that AI creates new vulnerabilities. It is that enterprises cannot reliably see the systems creating them.

Snyk introduced its AI Security Fabric in February 2026 as a layer spanning software development and agentic systems. The company said its approach would combine visibility, prevention, and governance across the software development lifecycle.

That product announcement included findings from Snyk’s 2026 State of Agentic AI Adoption research. According to the company, its analysis covered anonymized insights from more than 500 enterprise Evo environments. Snyk said every deployed AI model was associated with nearly three times as many hidden components, including datasets and third-party tools.

The headline claim takes that observation further. Snyk says roughly two-thirds of enterprise AI risk lies below the most visible model layer. The concealed portion includes agent tools, plugins, connected repositories, external services, and data pipelines that employees attach during development or daily work.

These components are not automatically malicious. A plugin may simply retrieve a document, call an internal API, or send an approved message. The security issue emerges from the relationship between the component, its permissions, its input sources, and its ability to trigger downstream actions.

A model inventory alone cannot capture those relationships. Two teams might use the same model through different agents with entirely different risk profiles. One agent may summarize public documents. Another may read source code, query customer records, and write changes into production systems.

That is why the story deserves more than a familiar warning about employees using unapproved chatbots. Shadow AI now includes embedded features inside approved software, locally deployed models, agent frameworks, browser extensions, automation services, and machine identities. Some arrive through formal procurement. Others appear when an employee connects one more tool to finish a task.

Google News gives this claim a broad distribution channel, but aggregation does not validate the underlying figure. Readers should treat the two-thirds estimate as a vendor finding drawn from Snyk’s customer-related environment data. The stronger conclusion rests on corroborating evidence: enterprises struggle to inventory agent behavior, permissions, and component dependencies.

That distinction protects the analysis from becoming product marketing. Snyk’s precise market-wide estimate remains open to testing. The visibility problem itself is already supported by multiple independent and standards-oriented sources.

The AI Attack Surface Is No Longer a List of Applications

The practical attack surface now behaves like a changing graph, where models, identities, tools, and data stores create risk through their connections.

Traditional application security starts with a relatively stable object. A team owns an application, maintains its repository, tracks dependencies, and deploys it through known infrastructure. Security tools can scan the code, packages, container images, cloud configuration, and exposed endpoints.

AI-native systems add more moving parts. Snyk’s analysis of AI-native applications describes a supply chain that can include pretrained models, embeddings, third-party agents, datasets, and external services. Each component can change independently of the application’s source code.

An embedding is a numerical representation used to compare the meaning of content. A vector database may store millions of these representations for retrieval. If permissions or source labels are wrong, an agent can retrieve information that its user was never meant to access.

Retrieval-augmented generation, often shortened to RAG, gives a model selected documents or records before it produces an answer. RAG can improve accuracy, but it also creates another trust boundary. The retrieval layer must decide which sources the agent can search and which content it should return.

Tools create a more consequential boundary. An agent connected to email, source control, cloud infrastructure, or a customer database can move beyond producing text. It can read, write, execute, approve, or transmit information, depending on the permissions developers gave it.

This creates a mismatch with security inventories organized around purchased applications. A company may have approved the model provider and the agent framework. It may still lack a complete record of every tool endpoint, service account, dataset, prompt template, or plugin attached after deployment.

The chain can also change without a traditional release. A model provider may update behavior. A third-party tool may add a function. A dataset may receive new documents. A user may expand an OAuth scope, which determines what an application can access through delegated authorization.

These changes matter because risk depends on combinations. A summarization agent with read-only access has a limited blast radius. Give the same agent permission to send email, edit files, and call an unrestricted web endpoint, and a manipulated input can produce a very different result.

The attack surface therefore includes more than vulnerabilities in code. It includes excessive permissions, poisoned context, exposed credentials, unsafe output handling, weak approval rules, and incomplete action logs. Several of these problems remain invisible to scanners that only inspect source files or known software packages.

For engineering teams, documentation becomes part of the control system. A searchable record of architecture decisions, approved tools, permission scopes, and incident findings helps teams identify relationships that individual dashboards miss. A structured engineering knowledge base can support that work, although it does not replace security monitoring.

The larger lesson is simple. An AI system cannot be governed as a single model endpoint. It must be treated as a connected application whose data, tools, identities, and actions remain visible throughout operation.

Agentic AI Puts Identity Controls Under Pressure

The fastest-growing blind spot sits where autonomous software inherits permissions designed for human users.

Cloud Security Alliance published agent identity research in March 2026. Its survey found that 73% of organizations expected AI agents to become vital within the following year. Yet 68% could not clearly distinguish actions performed by agents from those performed by people.

The similarity between that 68% figure and Snyk’s roughly two-thirds warning is striking, but the figures measure different things. Snyk discusses hidden components and risk across AI environments. The Cloud Security Alliance survey examines identity attribution and access management.

Together, they reveal the same structural weakness. Organizations are giving software identities access to business systems faster than they are updating authentication, authorization, and monitoring practices.

A machine identity is a credential used by software rather than a person. It can take the form of an API key, service account, certificate, workload identity, or OAuth token. Agents depend on these credentials to access data and perform actions.

Human identity systems usually assume that a person signs in, receives a defined role, and generates activity linked to that account. Agents complicate this model. One agent may act for several users, call several tools, and create a chain of machine-generated operations within seconds.

Attribution becomes especially difficult when an agent uses a shared service account. Logs may show that the account changed a record or downloaded a file. They may not identify the employee request, model decision, retrieved document, or plugin call that caused the action.

This is not merely an auditing inconvenience. Weak attribution makes incident containment harder. A security team cannot confidently revoke the right credential if it does not know which agent, user, or workflow initiated suspicious activity.

Overprivileged access increases the damage. A tool built only to summarize messages may receive permission to send or delete them. A code assistant may obtain write access across multiple repositories when it only needs to review one project.

OWASP describes this condition as excessive agency. Its guidance identifies excessive functionality, permissions, and autonomy as root causes. OWASP recommends limiting available tools, narrowing permissions, executing actions in the user’s context, and requiring approval for high-impact operations.

Those controls resemble mature zero-trust practices. Each request should be evaluated using a specific identity, defined authorization, and current context. The model should not decide by itself whether an operation is permitted.

The agent also needs an identity distinct from its human operator. Logs should preserve the relationship between the user’s request, the agent instance, the selected tool, the credential used, and the resulting action. Without that chain, companies can collect enormous volumes of telemetry and still remain blind.

This is where AI adoption pressures security architecture. Business teams want assistants that remove repetitive approvals and complete multi-step tasks. Security teams need checkpoints, narrow permissions, and reconstructable decisions. Removing every checkpoint increases speed, but it also expands the potential blast radius of a wrong or manipulated action.

The conflict will not be solved by choosing full autonomy or banning agents. Enterprises need different autonomy levels for different consequences. Drafting a summary can remain automatic. Sending funds, deleting records, changing production infrastructure, or disclosing protected data should require stronger controls.

The Real Tradeoff Is Speed Versus Verifiable Control

Enterprises gain value when agents cross system boundaries, but every additional connection makes behavior harder to verify.

Agentic AI appeals to companies because it can connect separate steps into one workflow. A support agent might read a ticket, retrieve account history, classify urgency, propose a response, and update the customer record. That sequence can reduce manual coordination.

The same sequence contains several security boundaries. The ticket can include untrusted text. The account history can contain protected data. The model can generate an unsafe tool instruction. The customer system can accept an update with lasting consequences.

Prompt injection makes this tradeoff concrete. Prompt injection occurs when crafted content changes how a model follows instructions. The content can come directly from a user or indirectly from a webpage, document, email, repository, or retrieved record.

A conventional application separates commands from data through strict syntax and access controls. Language models process both as tokens within context. That design makes it difficult to guarantee that a model will always treat external text as untrusted data rather than an instruction.

OWASP’s current guidance says no foolproof prompt-injection prevention method is known. It recommends constraining behavior, validating expected output formats, filtering inputs and outputs, and limiting the permissions available to the model.

Those mitigations reduce impact, but they do not create certainty. An agent that can only read a narrow document collection presents less danger than one that can execute shell commands. A human approval step can catch suspicious actions, but only if the reviewer receives enough context to make an informed decision.

Speed pressures each safeguard. Teams may grant broad access to avoid repeated integration work. They may use shared credentials because per-user authorization takes longer to implement. They may suppress approval prompts after users complain about friction.

That makes the core contest a tradeoff between deployment speed and verifiable control. Snyk is arguing that security must become continuous because AI systems change too quickly for occasional reviews. The company’s commercial interest is clear, since it sells products positioned around that requirement.

Buyers should therefore separate the diagnosis from the proposed platform. A unified security layer might improve visibility, but no vendor has proven that one product can observe every model, local deployment, browser tool, dataset, identity, and external integration across a large enterprise.

Coverage claims depend on integrations and telemetry. An approved cloud model may be easy to detect. A locally hosted model on a developer workstation may not be. An AI feature inside a familiar software package may generate activity that looks like ordinary application traffic.

Encrypted connections and privacy rules introduce further limits. Monitoring prompts or retrieved documents can expose sensitive employee and customer data. Security teams need enough context to detect misuse without building a second repository of confidential information.

Regional data rules add another constraint. A multinational company may not be able to centralize all AI interaction logs. It may need local processing, selective metadata, retention controls, and different monitoring policies for different jurisdictions.

These complications do not invalidate Snyk’s warning. They strengthen its central point while challenging any simple solution. Visibility is necessary, but visibility itself creates design, privacy, and operational costs.

What the Two-Thirds Claim Does Not Prove

Snyk’s data signals a serious governance gap, but it does not establish that two-thirds of every enterprise environment is compromised or exploitable.

The most important limitation is sampling. Snyk describes anonymized insights from more than 500 enterprise Evo environments. Organizations using that environment may differ from the broader market in size, software practices, AI maturity, or security priorities.

The company has not publicly established that its sample represents every industry or geographic region. It also has a commercial reason to define the problem in terms that favor broader security coverage. Neither issue makes the data false, but both require careful attribution.

“Risk” is also broader than “vulnerability.” A hidden component may be unmanaged or insufficiently inventoried without containing an exploitable flaw. It becomes dangerous when combined with weak permissions, sensitive data, unsafe inputs, or the ability to perform consequential actions.

Likewise, “two-thirds” does not mean security teams see exactly one-third of every environment. The estimate summarizes patterns in observed environments. Individual organizations can have much better or worse coverage.

The phrase “attack surface” can further blur different problems. It may include internet-facing assets, internal APIs, software dependencies, agent tools, data flows, identities, and model behavior. Different vendors count these elements differently.

Independent measurement will require shared definitions. Researchers need to distinguish known assets from unknown assets, reachable components from dormant components, and theoretical exposure from demonstrated attack paths. Without those distinctions, large percentages attract attention but offer limited operational guidance.

NIST provides a more neutral foundation through its AI Risk Framework. The framework organizes work around governing, mapping, measuring, and managing AI risks. It also emphasizes that risk management should continue throughout the system lifecycle.

Mapping is particularly relevant to Snyk’s claim. An organization must identify the model, intended task, users, data, dependencies, deployment context, and affected parties before it can measure risk. A scanner cannot recover every missing policy or ownership decision.

Measurement also needs testing. A company may document an agent’s intended permissions but never verify its effective permissions in production. It may record approved tools while overlooking functions added through an updated integration.

The skeptical position is therefore not that the blind spot is imaginary. It is that one vendor’s telemetry cannot yet define its exact size across the market. The headline should motivate inventory and testing, not become a substitute for either.

Security leaders should ask vendors how they calculate coverage. They should request the denominator, detection methods, excluded environments, update frequency, and process for resolving duplicate or stale assets. A precise percentage without that context can create false confidence.

They should also measure outcomes. Finding more components is useful only if the organization can prioritize dangerous relationships, assign owners, reduce permissions, and remediate verified paths. A larger inventory that produces an unmanageable alert queue can become another form of blindness.

Three Signals Will Show Whether the Blind Spot Is Closing

The next phase will be measured through identity attribution, component inventories, and verified reductions in dangerous agent permissions.

The first signal is whether enterprises can separate agent activity from human activity in their logs. The Cloud Security Alliance’s 68% finding provides a clear baseline, even though it comes from a survey rather than direct telemetry.

Improvement would mean each consequential action carries an agent identity, user delegation, tool name, authorization context, and traceable result. If later surveys show fewer organizations struggling with attribution, the case for manageable agent governance becomes stronger.

If the number remains near two-thirds, the opposite conclusion follows. Enterprises will have deployed more autonomous workflows without solving basic accountability. That outcome would strengthen Snyk’s warning that the visibility gap is growing with adoption.

The second signal is the emergence of consistent AI bills of materials. An AI bill of materials records models, datasets, prompts, frameworks, tools, services, and dependencies used by a system. It extends the software bill of materials concept to AI-specific components.

The useful version must stay synchronized with deployment. A static document created during procurement will miss the tools and datasets connected later. Automated discovery, owner assignment, version history, and evidence of effective permissions matter more than simply producing a list.

Broad adoption of interoperable inventory formats would strengthen the argument that enterprises can regain visibility. Continued reliance on vendor-specific dashboards would leave blind spots between security products, cloud platforms, and local environments.

The third signal is whether organizations reduce excessive agency in production. Security teams should track how many agents can write data, execute code, send communications, alter infrastructure, or access sensitive repositories without a separate approval.

A falling number would show that companies are translating AI governance into technical controls. A rising number would indicate that productivity goals still outweigh containment. Incident reports involving overprivileged agents would make this metric especially urgent.

These signals matter more than the volume of AI policies published by companies. Policies describe intent. Identities, inventories, permissions, and logs reveal the operating reality.

Snyk’s Google News headline succeeds because it compresses that reality into one memorable warning. The exact two-thirds figure remains a vendor-derived estimate, but the underlying mismatch is difficult to dismiss. AI components are multiplying faster than many organizations can discover, classify, and govern them.

For developers, the immediate question is whether every agent connection has a named owner and a necessary permission. For security teams, it is whether logs can reconstruct an action from user request through model decision to downstream result. Enterprise buyers should demand evidence for both.

The next quarter offers a practical test. Pick one production agent, map every model, tool, identity, dataset, and external call, then compare that map with existing security records. If the two views differ sharply, the blind spot is already inside the organization. If they match, test whether permissions and approval controls behave as documented. Google News supplied the warning; enterprise telemetry must now supply the answer.