TL;DR: 81% of organisations running AI packages have at least one known vulnerability, 29.5% store an AI credential insecurely, and 87% to 98% of AI workloads lack customer-managed encryption across major clouds, according to Orca Security’s 2026 State of AI Security Report. The security gap is now operational, not theoretical, and it demands identity discipline as much as patching.
NHIMG editorial — based on content published by Orca Security: 2026 State of AI Security Report
By the numbers:
- 81% of organizations running AI packages have at least one known vulnerability, with an average CVSS of 8.79
- 50.1% of AI vulnerability alerts now have a public exploit available, up from just 0.2% in our 2024 report
- 29.5% of AI adopters have at least one AI credential stored in an insecure location
Questions worth separating out
Q: How should security teams handle AI credentials that function like non-human identities?
A: Treat AI credentials as privileged identities, not just application configuration.
Q: Why do AI agents increase cloud access risk even when the model is secure?
A: Because the risk often sits in the delegated permissions around the agent, not in the model itself.
Q: What do organisations get wrong about AI vulnerability management?
A: They often optimise for severity scores while ignoring exploit availability and exposure path.
Practitioner guidance
- Inventory AI credentials as privileged secrets Map every AI API key, token, certificate, and service principal used by model, agent, and RAG workflows.
- Prioritise exploitability over severity alone Re-rank AI package vulnerabilities using public exploit availability, internet exposure, and production placement.
- Scope agent permissions to task-level access Define the cloud and data permissions each agent can use, then review them as separate identities with explicit owners.
What's in the full report
Orca Security's full report covers the operational detail this post intentionally leaves for the source:
- Per-environment telemetry across AWS, Azure, and Google Cloud showing how AI package exposure and misconfiguration vary by platform.
- The detailed remediation roadmap for days 0 to 30, 30 to 90, and 90 plus, including hardening steps for AI services and agent frameworks.
- Year-over-year comparison tables that show how exploit availability, patching lag, and encryption coverage changed from the 2024 baseline.
- The specific AI security dashboard and platform context used to identify running models, managed services, and exposure paths.
👉 Read Orca Security's 2026 State of AI Security Report →
AI security exposure in 2026: what IAM and cloud teams must fix?
Explore further
AI security debt is now identity debt: the report shows that AI programmes fail in the same places NHI programmes fail, namely secret handling, privilege scoping, and lifecycle discipline. Once an AI system has credentials and data access, the question becomes who owns those rights and how they are removed. Practitioners should treat AI access as governed identity, not as a side effect of model deployment.
A question worth separating out:
Q: Who is accountable for securing AI workloads and credentials?
A: Accountability should sit with the teams that own the AI service, the cloud environment, and the data it touches, with clear control ownership for secrets, encryption, and access review. AI governance fails when it becomes everyone’s concern and nobody’s responsibility. The ownership model should be explicit before production use.
👉 Read our full editorial: 2026 AI security risk is now an identity and exposure problem