2026 AI security risk is now an identity and exposure problem

At a glance

What this is: This report shows that AI security risk has moved into production infrastructure, with widespread vulnerabilities, exposed AI credentials, unmanaged agents, and weak encryption controls.

Why it matters: It matters because AI platforms now rely on the same identity, secret, and access decisions that govern NHI and cloud workloads, so IAM teams must treat AI security as an access-control and governance problem.

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
• Between 87% and 98% of AI workloads across the three major cloud providers lack customer-managed encryption

👉 Read Orca Security's 2026 State of AI Security Report

Context

AI security has shifted from experimental risk to production governance. The article argues that organisations are deploying AI faster than they are securing the packages, credentials, agents, and cloud services that support it, which turns AI exposure into a routine control problem rather than a future scenario. For identity and access teams, the key issue is that AI systems inherit privilege, secrets, and data access decisions from the same foundations used for non-human identities.

The report’s core message is that security controls around AI now need the same discipline applied to cloud and identity programmes. That means treating AI credentials as secrets, agent permissions as governed access, and model-adjacent infrastructure as part of the attack surface, not an isolated innovation tier. In practice, the starting position described in the article is now typical rather than exceptional.

Key questions

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. Assign ownership, track where each secret is used, rotate or replace static values, and remove insecure storage in repositories, notebooks, and shared files. If a credential can authenticate to models, data pipelines, or cloud resources, it needs the same governance discipline as other non-human identities.

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. If an agent can query data, call tools, or write to cloud services, broad access becomes a governance issue. Teams should review the permissions, data boundaries, and owners for each agent before production deployment.

Q: What do organisations get wrong about AI vulnerability management?

A: They often optimise for severity scores while ignoring exploit availability and exposure path. A package with a public exploit and production reach can be more urgent than a higher-scoring issue in a non-critical environment. Effective programmes rank AI vulnerabilities by exploitability, runtime exposure, and business criticality.

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.

Technical breakdown

Why AI package exploitability changes the patching model

The report shows a classic security timing problem: vulnerability discovery has outpaced remediation and exploit availability has changed the risk profile. When half of AI vulnerability alerts now have a public exploit, severity scores alone no longer tell the full story. Teams need to prioritise based on exploitability, package exposure, and whether the vulnerable component sits in a production AI path. That is the difference between a theoretical finding and an active entry point.

Practical implication: tie AI package patching to exploitability and runtime exposure, not just CVSS.

AI credentials behave like high-value non-human identities

A compromised AI API key grants authenticated access to models, RAG-connected data, and usage-based compute, which makes it functionally similar to a privileged NHI. The report’s point is that these credentials often sit in insecure locations and can expose more than one provider at once when organisations use multiple AI services. That creates a broader blast radius than many teams expect because the same secret can unlock both data flow and inference capability.

Practical implication: inventory AI credentials as privileged secrets and remove static storage wherever possible.

Agent frameworks create a cloud permission problem, not just a model problem

Once AI agents run in production, they operate with real cloud permissions and can act on enterprise data through RAG pipelines and connected services. The governance failure is not the model itself, but the access path around it: who issued the permissions, what they cover, and how much data the agent can reach. If those permissions are broad, the agent becomes an additional execution layer with inherited trust.

Practical implication: scope each agent’s permissions and data reach before production deployment.

Threat narrative

Attacker objective: The attacker wants authenticated control over AI infrastructure, access to data flowing through AI systems, and the ability to monetise, steal, or manipulate those resources.

1. Entry begins when attackers find exposed AI credentials, vulnerable packages, or insecure AI infrastructure defaults that provide authenticated access or a usable foothold.
2. Escalation follows when those credentials or package weaknesses allow access to enterprise data paths, RAG stores, cloud permissions, or inference resources beyond the original target.
3. Impact occurs when attackers hijack model usage, exfiltrate data, abuse cloud spend, or expand access across multiple AI providers and connected workloads.

NHI Mgmt Group analysis

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.

Exposed AI credentials create a new standing-access window: the article’s 29.5% insecure-storage finding matters because credential leakage turns AI systems into instant authenticated targets. That is the same governance failure seen in NHI breaches, where a static secret outlives its intended scope. Practitioners should assume any AI secret in a repository, notebook, or config file is already part of the attack surface.

Agentic AI expands the control problem from authentication to delegation: production agents do not just consume prompts, they act through cloud permissions and data pipelines. That means access reviews must include delegated actions, not just human approvals or model endpoint access. Practitioners should align this with OWASP NHI Top 10 and the NHI lifecycle, because agent permissions need ownership, review, and revocation like any other privileged identity.

Cloud encryption gaps show that AI governance is still being bolted on: if 87% to 98% of AI workloads lack customer-managed encryption, then data protection is not yet embedded in AI operating models. The issue is not only confidentiality, but control of who can read, move, and retain model-adjacent data. Practitioners should view encryption as part of the minimum control baseline for AI governance, not as a post-deployment enhancement.

What this signals

AI governance debt is becoming an operational identity problem: as AI systems move into production, IAM and PAM teams will be asked to govern secrets, delegated access, and revocation at machine speed. The practical signal is that existing review cycles are too slow for AI-native change, so programmes need continuous inventory and ownership mapping rather than periodic clean-up.

Agent permissions will need their own lifecycle controls: the report’s findings point to a new control boundary where access review must cover not only humans and service accounts, but AI agents that can call tools and act on data. That aligns closely with the NHI lifecycle model and with the governance patterns described in the The 52 NHI breaches Report.

Encryption and secret handling will become board-level evidence of AI control maturity: if AI workloads can read sensitive data without customer-managed encryption, the programme is not just technically exposed, it is governance-light. Teams should expect scrutiny on where AI data lives, who can decrypt it, and how quickly credentials are revoked when an AI service changes purpose.

For practitioners

• Inventory AI credentials as privileged secrets Map every AI API key, token, certificate, and service principal used by model, agent, and RAG workflows. Eliminate insecure storage in code, notebooks, and shared documents, then require short-lived or managed identities wherever the platform supports them.
• Prioritise exploitability over severity alone Re-rank AI package vulnerabilities using public exploit availability, internet exposure, and production placement. Build patch queues that pull forward exposed packages with working exploits even when the numeric score is not the highest.
• 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. Remove broad inherited rights, especially where agents can reach vector databases or trigger downstream actions.
• Enable customer-managed encryption for AI workloads Apply customer-managed encryption to model inputs, outputs, training data, and related storage across all clouds. Use it as a baseline control for any AI workload that handles sensitive data or regulated records.
• Embed AI checks into deployment pipelines Block AI services from reaching production until configuration checks verify root access is disabled, defaults are hardened, and secret handling is controlled. Treat these checks as release gates, not post-deployment reviews.

Key takeaways

• AI security in 2026 is primarily a control problem around vulnerabilities, credentials, agent permissions, and encryption.
• The report shows that exploitability and insecure secret storage now create immediate risk across production AI environments.
• IAM, PAM, and NHI governance need to extend into AI deployments before those systems accumulate more standing access.

Key terms

• AI Credential: A credential used by an AI service, model workflow, or agent to authenticate to data, cloud, or inference resources. In practice, these are API keys, tokens, certificates, or service principals that should be governed as privileged secrets because leakage gives attackers immediate access.
• Agent Framework: A software layer that lets an AI system call tools, reach data, and perform actions inside production environments. It matters because the framework often inherits cloud permissions and data access, so governance must cover delegation, ownership, and revocation as much as model behaviour.
• Customer-Managed Encryption: A data protection model where the organisation controls the encryption keys rather than relying entirely on the service provider. For AI workloads, it helps protect prompts, model outputs, training data, and related storage while preserving control over who can decrypt sensitive information.
• RAG Pipeline: A retrieval-augmented generation path that lets an AI system pull external content into its responses or actions at inference time. When connected to enterprise data, the pipeline can expand blast radius if credentials are exposed or access controls are too broad.

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.

👉 Orca Security's full report covers the year-over-year telemetry, remediation roadmap, and platform-level exposure details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It is designed for practitioners who need to extend identity discipline into AI and cloud operations.