October 21, 2026
0 mins read New Snyk research across thousands of scanned enterprise environments shows why a high model-risk score marks where triage begins, and how security teams should respond.
Imagine two applications that reference the same AI model. One summarizes meeting notes, and the other uses an agent to query customer records and trigger business workflows. The model might carry the same adversarial test scores into both applications. But the consequences of a failure could be very different, and so could the failure that matters. A meeting summarizer needs to know whether the model can be pushed into misleading output. A customer records agent needs to know whether it can be made to leak data or take unauthorized actions. That’s why a model score for each type of attack is more useful than one average across all of them.
That distinction is at the heart of Snyk’s 2026 State of Agentic AI Adoption, Volume III. The first two volumes established that enterprise AI is a connected software estate, not just a collection of models. This new analysis adds risk scores for identifiable models and asks the question security leaders actually need answered: Which findings require action, and what action will reduce the risk?
Nearly half of AI model inventories contain a critical-scoring reference #
How the scores work: Snyk tests each model against 29 attacker goals, such as extracting personal data or executing commands, and scores each from 0 to 1,000. The score combines how often an attack succeeded with how much damage that goal could do. 500 and above is high, 750 and above is critical. Models are tested behind a basic guardrail, so the scores describe a defended model, not an undefended one.
Of 1,693 environments with at least one detected model identifier, 74.5% reference a model that scored high (500+) on at least one attacker goal, and 49.2% reference one that scored critical (750+). PII extraction and command execution account for the critical-band findings observed in this sample.
Those numbers should prompt investigation, not panic. The research matches model identifiers found in code to adversarial test results. It does not establish that every model is active in production, that a particular tool or dataset is accessible, or that an attack has succeeded in an organization's application.
Coverage is another reason to be precise: only 37.5% of detected model occurrences have a matched risk score. About 17% of model-bearing environments have no scored model at all. Treat unscored and versionless references as unknowns that still need review.
Inventory size changes the count of findings but not the mix. The chance of finding at least one high-scoring model rises from 34.6% of the smallest model estates to 100% of the largest, yet the share of model occurrences linked to high-scoring models stays between 21% and 25% at every size, and between 18.9% and 25.5% across eight industries. Use the count to size the review backlog and the share to benchmark model choices against peers. Neither number shows what an active application permits a model to do.
For every high-scoring model, the first questions are: Is it active, what can it reach, and what happens if it fails?
Agents and MCP servers make the deployment context impossible to ignore #
A model can produce an unsafe answer on its own. Connected to tools, data, and workflows, it may also be able to act on that answer. That's the difference between a model's tested exposure and the reach of the system around it.
Of the 1,051 US accounts with an MCP reference, 744 (70.8%) show evidence of building an MCP server with an SDK. The rest show only client connections or configuration references. Building a server, configuring one, and operating one are three different signals, and only runtime verification confirms the last.
Among environments with no detected agent or MCP signal, 49.1% reference a high-scoring model, compared with 96.6% of those with both an agent indicator and MCP server-building code.
The latter group also runs a much larger median model inventory: 104 models versus 4. Comparing environments with 5–19 models narrows the gap from 47 points to 26 (62.1% versus 87.8%). The pattern is an association. What agents and MCP servers change is how far a model’s score can reach, which is why they’re the place to look first.
For security teams, the next step is verification: confirm which agents and MCP servers are active, which tools they expose, what data they can retrieve, and what approvals stand between a model's output and a consequential action. A model score cannot answer those questions.
Don’t prescribe the same fix for every AI weakness #
Once you know what a model can reach, the next question is which fix fits the failure. A useful model-risk program doesn't stop at severity bands. It asks which attacker goal matters for the application and whether another model performs meaningfully better on that goal. The answer splits two ways:
- Where switching models can help. For command execution, 77% of the tested models scored zero, while the worst reached 834. For code backdoors, 57% scored zero, while the worst reached 695.
- Where application controls do the work. On misinformation, the median model reached the maximum possible score. On race bias, no tested model scored zero.
A zero means no attack succeeded in that test, and a model that performs well on one goal can perform poorly on another, so validate any replacement against every goal the workload depends on. Where results cluster, the defense sits in the application: limit access, validate outputs, require approvals, monitor use, and scan generated code and dependencies before they enter a build.
Alert thresholds also tell only part of the story: 18 of the 29 attacker goals can never reach the default alert threshold of 500, because the damage each one can do caps its maximum score below it. Those failures still matter when the alert queue is quiet.
When models differ, test a replacement. When they don’t, reduce the application's access and authority.
Which goals can switching models actually fix, and which will never raise an alert? See all 29 charted. Download the full report**.**
Your approved model list may need a second look #
Familiarity, license, and price are poor substitutes for examining the specific model.
Lower-capability models deserve review first
In the scored group, lower-capability models performed worse on personal data leakage, decision override, and insecure code generation. On decision override, the average fell from 501 for models below 130 on the Epoch Capabilities Index (ECI) to 45 for models at 150 ECI or above. Those lowest-capability models account for roughly one-third of model occurrences in the scored comparison, so the finding reaches well beyond an edge case.
Capability is a separate measure from security, and a stronger model still needs to be tested against the task it will perform. Revisit lower-capability approved versions and test alternatives from the provider you already use, since the pattern also appears within individual providers’ lineups.
Provider is a useful first signal, though it tells you less at the frontier. Among mid-range models, provider averages range from 113 to 356; among the most capable, three leading providers land within 22 points of one another. If your approved list leans on one provider, the full report shows where its models lead and where they lag. Six providers are compared side by side across seven attack types, from data exfiltration to output manipulation. Premium price tiers showed no consistent security advantage in this sample, largely because the high-price tier is mostly older, lower-capability models.
Open-weight models and training-data lineage
The report also finds higher personal data leakage scores among the 16 scored open-weight models than among proprietary models: 562 versus 274, on average. It’s a small sample size, so treat the difference as a signal worth investigating for workloads that handle personal data.
Lineage visibility follows the same split. In 904 of 1,693 model-bearing environments, scans found no training-data lineage, largely because proprietary model providers do not publish their training datasets. The evidence therefore depends on the model type: ask proprietary vendors for documented assurances, and inspect the dataset lineage that open-weight models publish.
Four actions for security leaders #
1. Inventory and qualify the unknowns: Track model identifiers, versions, owners, active uses, agents, tools, MCP servers, and available lineage. Keep unmatched models visible; do not silently treat them as low risk.
2. Verify the reach: Confirm the runtime path from each active model to sensitive data, credentials, tools, and downstream actions. Distinguish server-building code from configuration and actual connections.
3. Make remediation goal-specific: Rank failures by their business consequences. Test named replacement models where adversarial results vary; use least privilege, output checks, approvals, and code scanning where they do not.
4. Turn the decision into governance: Record the model and version, test evidence, owner, approved controls, rationale, and review date. Reassess when models, permissions, fine-tuning data, or applications change.
The takeaway from Volume III: a model’s score shows its exposure, and the system around it decides its reach. Act on both, switch models where they differ, and tighten controls where they don’t
Methodology: Anonymized, aggregated AI bill of materials (AI-BOM) scan data from organizations that use Snyk, beginning September 2026: 3,023 environments, including 1,693 with at least one model identifier. Model-level findings cover US accounts.
Security leaders need to know which failures could matter to their business and which control changes the outcome. Which agent and MCP pattern describes your environment, and how does your provider compare across seven attack types? The full report breaks out both, plus the industry and price-tier results and the six questions every governance leader should be able to answer. Download the 2026 State of Agentic AI Adoption, Volume III.
Ready to assess your own AI estate? Explore Evo AI-SPM**.**
You can’t govern AI you can’t see
Start with Discovery. Start with Evo AI-SPM. #
Uncover every AI component hidden in your codebase and apply organization-wide governance.