Cobalt’s latest AI pentesting research lands on a problem many security teams are already feeling: companies are testing AI applications more often, but the serious findings are still getting fixed too slowly.
In the AI and Pentesting Pulse Report 2026, released June 25, Cobalt said only 9% of surveyed security professionals now support fully automated pentesting, down from 29% a year earlier. The company’s survey of 455 cybersecurity professionals also found that 47% now prefer a hybrid model that combines automation with human security testing.
The shift is not just skepticism toward AI tools. It reflects the way AI and large language model applications fail. Cobalt said 78% of organizations had seen fully automated scanning tools miss critical vulnerabilities, while AI and LLM applications produced high-risk findings at 2.7 times the overall rate in its broader pentest data. In the company’s separate State of Pentesting Report 2026, 32% of AI and LLM findings were rated high risk, compared with 12% across the full dataset.
The Testing Gap Is Becoming a Remediation Gap
The most useful number in Cobalt’s research is not the adoption figure. It is the fix rate. At the time of analysis, only 38% of LLM vulnerabilities had been fixed, leaving 62% open. Cobalt described that as the lowest resolution rate across the pentest categories it tracks.
That matters because AI security findings often cut across product, data, identity, legal, and infrastructure teams. A traditional web-app vulnerability might map cleanly to one service owner and one code path. An LLM issue may involve prompt design, retrieval permissions, plugin behavior, model output handling, tenant isolation, logging, data-retention rules, and abuse monitoring. The ownership map is messier, so remediation can stall even after a tester proves the risk.
Cobalt’s reported mean time to resolve AI and LLM security issues rose from 19 days in 2025 to 36 days in 2026. That increase can be read two ways. Teams may be catching harder issues now that AI testing is more mature, but it also means unresolved exposure is lasting longer in systems that are often being shipped quickly and connected to sensitive business workflows.
Why Ordinary Scanners Miss AI Risk
AI application vulnerabilities are rarely limited to one bad input field. Common failure paths include prompt injection, excessive agency, data leakage through retrieval systems, unsafe tool calls, overbroad plugin permissions, weak output handling, and supply chain exposure in model, prompt, dataset, or orchestration components. The risk depends heavily on what the application can see, what it can do, and which user or service identity it acts through.
That is why scanner-style coverage can look better on paper than it performs in practice. A tool may identify an exposed endpoint, dependency issue, or malformed response, but miss the business logic of an AI workflow: whether a user can trick a support assistant into revealing another customer’s information, whether a code agent can execute a risky command, or whether an internal knowledge bot can combine documents in a way that bypasses intended access boundaries.
Cobalt’s press release highlighted shadow AI as the top contributor among organizations with confirmed AI-related incidents, followed by data or model poisoning, improper output handling, supply chain vulnerabilities, and prompt injection. Those categories do not behave like ordinary patch tickets. They often require product constraints, data-governance changes, narrower permissions, new approval gates, and better runtime detection.
What Security Teams Should Change
The wrong conclusion is that AI testing tools are useless. Automation is still valuable for repeatable checks, broad asset coverage, regression testing, and low-risk environments. Cobalt’s survey found that 47% of security professionals favor using automation for low-risk environments, even as trust in fully automated pentesting has fallen.
The better conclusion is that AI security programs need a clear path from test finding to fix validation. For teams shipping LLM-backed products, that means treating AI findings as product-security work rather than research notes. A prompt-injection finding should identify affected flows, reachable data, tool permissions, abuse preconditions, expected telemetry, owner, severity, compensating controls, and retest criteria.
- Define the AI asset clearly. Inventory the model, orchestration layer, retrieval sources, plugins, tools, identities, logs, and customer-facing surfaces that make up the application.
- Test the workflow, not just the model. Include indirect prompt injection, poisoned documents, malicious tool outputs, unsafe file handling, and cross-tenant data paths.
- Assign owners before testing starts. AI findings can cross many teams, so remediation ownership should be agreed before the report lands.
- Separate low-risk automation from high-risk validation. Use automated checks where they are strong, but keep human-led testing for business logic, chained attacks, and agent behavior.
- Retest after mitigation. Prompt changes, filters, and policy text are not fixes unless the exploit path is actually blocked under realistic conditions.
The Board-Level Question Is Not Whether AI Was Tested
Cobalt’s broader pentesting research also points to a maturity divide. Its State of Pentesting page says top-performing teams have a 10-day half-life for high-risk findings, while the bottom tier leaves high-risk findings exploitable for a 249-day half-life. The company’s research frames that as a program problem: organizations that treat offensive security as a continuous process fix faster than those that run tests as periodic compliance exercises.
That distinction is especially important for AI products because the attack surface changes when teams add new tools, files, data sources, model versions, integrations, prompts, and agent permissions. A single annual assessment will not capture how fast the system changes. Security teams need testing tied to release gates, retrieval changes, new tool permissions, and production incident signals.
The practical board-level question is no longer simply whether an AI product had a pentest. It is whether serious findings are being fixed, retested, and tracked to closure before the product’s capabilities expand. Cobalt’s numbers suggest many organizations have accepted the need to test AI systems. The harder work is building the product and security process that can absorb what those tests reveal.
