Top AI security vulnerabilities in 2026 are outpacing enterprise controls

At a glance

What this is: Cycode maps 11 AI security vulnerability classes for 2026 and argues that enterprise controls are not keeping pace with how AI is being embedded into code, workflows, and connected systems.

Why it matters: For IAM and security teams, the key issue is that AI now behaves like a governed system access layer, so visibility, least privilege, and output validation must extend into AI interactions and delegated actions.

By the numbers:

• 81% lacking visibility into how AI is actually used shows that many enterprises cannot govern AI activity they cannot see.

Context

AI security now sits at the intersection of application security, data governance, and identity control. Once AI systems can read enterprise data, call tools, generate code, or trigger downstream actions, traditional perimeter thinking stops being enough because the risk is no longer only model misuse but uncontrolled access and unverified output.

The article’s core point is that AI vulnerabilities are operational, not theoretical. That makes them relevant to IAM and NHI programmes whenever AI assistants, agents, plugins, or APIs inherit permissions that were never designed for machine-speed decision-making. In practice, the control problem is about who or what can act, on what data, and with what level of trust.

Key questions

Q: How should organisations stop prompt injection from becoming a code or data breach?

A: Treat prompts, retrieved content, and external inputs as untrusted by default. Separate instruction sources architecturally, filter adversarial text before it reaches the model, and restrict tool access so a successful injection cannot immediately trigger code execution, data exposure, or downstream action without additional controls.

Q: Why do AI systems create identity and access risk beyond traditional AppSec?

A: Because AI systems often act through delegated access. When a model can use tools, retrieve data, or trigger actions, it becomes a runtime decision-maker with privileges that can be misused through prompt injection, poisoned context, or overbroad permissions. That is an identity problem as much as a code problem.

Q: What do security teams get wrong about user feedback on AI outputs?

A: They often treat user ratings as neutral truth, when they are shaped by friction, adoption bias, and who chose the tool in the first place. A high rate of positive feedback can hide low response rates from unhappy users, while negative feedback can overstate failure if the rollout audience is unusually critical.

Q: How can organisations tell whether AI governance is actually working?

A: Organisations can tell AI governance is working when they can inventory every agent, explain its purpose, show who owns it, and prove that permissions are tightly scoped. If those four things are missing, the programme has policy language but not operational control. Auditors will notice the gap quickly.

Technical breakdown

Prompt injection and instruction boundary failure

Prompt injection works because many AI systems treat instructions, user input, retrieved content, and tool context as a single text stream. That collapses the boundary between trusted system instructions and untrusted external content, allowing attackers to smuggle commands through documents, emails, pages, or pull requests. In agentic workflows, the impact grows because the model is not only generating text but also selecting tools and actions. The architectural weakness is not the prompt itself but the absence of a hard trust boundary around instruction sources and execution privileges.

Practical implication: isolate system instructions from external content and constrain tool permissions so injected text cannot become execution.

Excessive agency and delegated access

Excessive agency appears when an AI agent receives more permissions than the task requires. That creates a machine-speed privilege problem similar to overprivileged service accounts, except the scope expands dynamically as the agent chooses actions. The article’s examples show why read, write, email, and finance access cannot be bundled into a general-purpose assistant without clear constraints. Once an agent can chain tool calls, the security issue becomes delegation without reliable human review. The real risk is not only compromise, but legitimate behaviour that exceeds intended authority.

Practical implication: scope each AI agent to task-specific entitlements and require approval before high-impact actions occur.

AI supply chain compromise and output trust

AI supply chain compromise extends beyond model files to datasets, plugins, MCP servers, and third-party dependencies. If one of those inputs is poisoned or tampered with, the resulting behaviour can look like normal functionality while carrying malicious logic, backdoors, or data exfiltration paths. Improper output handling is the downstream version of the same problem: unverified model output is consumed as if it were safe input. Together, these failures show that AI systems need provenance controls and schema enforcement, not just content moderation.

Practical implication: verify provenance for every AI dependency and validate all model outputs before they reach another system.

Threat narrative

Attacker objective: The attacker aims to turn AI trust, delegated access, or unverified output into data theft, unsafe execution, or control of enterprise workflows.

1. Entry begins when attackers use prompt injection, poisoned content, or compromised AI dependencies to influence an AI system’s behaviour or trust boundary.
2. Credential or permission abuse follows when the AI agent or connected workflow is allowed to access data, tools, APIs, or code paths beyond the intended scope.
3. Escalation occurs when malicious prompts, poisoned retrieval data, or unchecked outputs drive the AI to execute harmful actions, exfiltrate data, or propagate insecure code.
4. Impact is unauthorized access, manipulated business decisions, exposed sensitive information, or downstream system exploitation through trusted AI workflows.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI governance debt is now a control failure, not a policy gap. The article shows that enterprises are already embedding AI into code, search, workflow automation, and agentic actions faster than they are instrumenting it. That creates governance debt because the organisation accrues AI risk faster than it can classify, approve, or monitor the system. Practitioners should treat AI control coverage as an operational dependency, not a future programme.

Delegated access is the new AI attack surface. The most consequential AI risks in the article are not abstract model problems but permission problems, especially where assistants can touch email, databases, CRM systems, or code repositories. That is where NHIs and agentic systems intersect: once the AI can act, it needs lifecycle governance, scoped entitlements, and revocation paths just like any other machine identity. The practitioner conclusion is to govern AI as an identity-bearing runtime, not as a chat interface.

Prompt boundary failure is the clearest named concept here: instruction trust collapse. This occurs when organisations fail to separate system instructions, retrieved content, and user input into distinct trust zones. The result is that untrusted text can become executable influence. Teams should treat that collapse as a design defect that requires architecture-level separation, not a filter-only problem.

AI supply chain risk now includes model provenance, plugin trust, and MCP exposure. The article makes clear that compromise can enter through dependencies that are not treated like traditional software components. That means AI governance needs the same discipline as software supply chain security, but with added attention to machine-readable permissions and workflow delegation. The practitioner conclusion is to extend assurance from code to model, plugin, and tool chain.

Output handling is where many AI controls fail to become real controls. An AI system that produces unsafe text, malformed commands, or untrusted code is still dangerous if another system consumes that output without verification. The issue is not generation alone but trust transfer between systems. Practitioners should therefore align AI governance with downstream validation, because the final security boundary is often outside the model itself.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Instruction boundary failure will remain the most common AI governance blind spot. The practical issue is not whether a model can be persuaded once, but whether the organisation has separated trusted instructions from untrusted content in a way that survives retrieval, tool use, and multi-turn interaction. Without that separation, prompt injection becomes a workflow control problem rather than a chatbot anomaly.

Machine identity governance now extends into AI runtime behaviour. As AI systems gain delegated access to data, tools, and APIs, they behave like non-human identities with dynamic privilege. That makes least privilege, logging, and revocation essential not only for service accounts but for agents whose authority is issued and consumed inside a single session.

AI-generated code and related content can reproduce risky patterns at scale. 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec. The operational response is to treat generation pipelines as security boundaries, not productivity shortcuts.

For practitioners

• Implement instruction boundary controls Separate system prompts from external content, retrieved documents, and user input so injected text cannot override trusted instructions.
• Constrain AI agent permissions Scope each agent to the minimum tools and data needed for one task, and require approval before database writes, emails, or other high-impact actions.
• Inventory all AI dependencies Track models, datasets, plugins, MCP servers, and connected APIs as governed assets so you can review provenance and revoke risky integrations quickly.
• Treat model output as untrusted input Validate, sanitise, and schema-check LLM output before it reaches another application, workflow step, or code path.
• Add detection for AI misuse patterns Monitor prompts, tool calls, unusual query sequences, and data-access patterns so abnormal agent behaviour is visible before it becomes an incident.

Key takeaways

• AI vulnerabilities are no longer limited to model safety. They now include instruction injection, delegated access, poisoned dependencies, unverified output, and insecure code generation.
• The article’s strongest evidence is governance visibility, not just threat variety. Cycode cites almost universal AI-generated code adoption and 81% lack of visibility into AI use.
• The control gap is architectural. Organisations need instruction boundaries, least privilege for AI agents, provenance checks, and output validation before AI becomes a routine attack path.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
• AI Supply Chain Attack: An AI supply chain attack is an attempt to compromise an AI system by tampering with the components it depends on. This can include poisoned training data, altered models, malicious libraries, compromised prompts, or injected tools. The goal is to influence outputs, steal data, or create hidden control paths.
• Improper Output Handling: A vulnerability where LLM-generated content is trusted before it reaches another system. The danger appears when that output is rendered, parsed, or executed without validation, encoding, or policy checks, allowing attackers to turn model responses into code, queries, or commands.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to apply identity discipline to AI agents, service accounts, and other non-human access paths.