Prompt injection attacks hit over 90 firms in 2025 as AI security risks escalate

Prompt injection is exploiting enterprise AI's biggest design flaws by targeting agents, RAG pipelines and model routers

In the past two years, businesses have been trying to fit large language models (LLMs) into support, analytics, development, and internal automation like never before. Along with the increasing adoption of AI technology, another trend is gaining momentum -- cybercriminals are taking advantage of the disconnect between assumptions about LLMs and their actual characteristics. In 2025 and 2026, several independent sources have highlighted the same trend: Prompt injection remains one of the most impactful and widely demonstrated attack vectors against LLM systems. The OWASP LLM Top 10 (2025) lists prompt injection as LLM01, identifying it as the most critical category of LLM‑specific vulnerabilities, for the second consecutive edition. OWASP's ranking reflects the fact that LLMs still struggle to reliably separate instructions from data, making them susceptible to manipulation through crafted inputs. CrowdStrike's 2026 Global Threat Report -- built on frontline intelligence across more than 280 tracked adversaries -- documented that threat actors injected malicious prompts into legitimate generative AI tools at more than 90 organizations in 2025. They then used those injections to generate commands that stole credentials and cryptocurrency. The report stated it plainly: "Prompts are the new malware." AI-enabled adversaries increased their overall attack volume by 89% year-over-year, with prompt injection working as both an entry point and a force multiplier. Real‑world incidents illustrate the operational impact. In August 2024, researchers at PromptArmor disclosed a prompt injection vulnerability in Slack AI that allowed an attacker to exfiltrate data from private Slack channels they had no access to -- including API keys shared in private developer channels -- by placing a malicious instruction in a public channel or embedding it in an uploaded document. In June 2025, researchers at Aim Security disclosed EchoLeak (CVE-2025-32711, CVSS 9.3), the first documented zero-click prompt injection exploit against a production AI system, targeting Microsoft 365 Copilot. By sending a single crafted email, no user interaction required, an attacker could cause Copilot to access internal files and transmit their contents to an attacker-controlled server. Both vulnerabilities were patched. These incidents underscore the fact that prompt injection is not a theoretical weakness but a practical, repeatable threat organizations must address as they deploy AI systems at scale. Prompt injection techniques have undergone major evolutions over recent years, now targeting multi-agent architecture, retrieval-augmented generation (RAG) pipelines, model routers, and long-term memory capabilities. The enterprise challenge: Too much trust Businesses deploy LLMs to process instructions, summarize information, and trigger automated workflows, but it is difficult for LLMs to tell: * Instructions from data * Information from context * Context from metadata * User intent from metadata This creates an opportunity for attackers to manipulate and influence the model's behavior, either directly or indirectly. Modern prompt injection Cross-model prompt injection LLM use is a common practice among enterprises. Attackers corrupt the output of a particular model, knowing well that other models would be processing the content. Hence, the corruption propagates through all AI systems. RAG supply chain poisoning Attackers create malicious information -- documentation, blog articles, GitHub READMEs. Then they wait until this malicious information is ingested in enterprises' RAG pipelines, then use it as an attack vector. Agent hijacking AI agents have evolved to the point where they can send emails, modify cloud infrastructure, execute code snippets, and interact with internal corporate systems. It takes just a single instruction to make agents act differently in a harmful manner. Context overflow attacks With the help of million-token context windows, attackers place malicious code within the document and hope that an LLM will stumble upon it and execute it, thus overriding all previous instructions. Memory poisoning Due to the implementation of long-term memory in LLMs, attackers can inject instructions that permanently reconfigure their state. Model‑router manipulation Enterprises increasingly use model routers to select between multiple LLMs. Attackers craft prompts that force routing to the weakest or least‑guarded model. Why this matters for business leaders Prompt injection is not a theoretical problem. It directly affects: * Customer‑facing systems (chatbots, support agents) * Internal copilots (developer tools, security assistants) * Automation workflows (ticketing, cloud operations, HR processes) * Data governance (RAG pipelines, knowledge bases) The risk is no longer limited to "the model said something it shouldn't." In 2026, prompt injection can: * Trigger unauthorized actions * Leak sensitive data * Corrupt internal workflows * Manipulate analytics * Alter business logic * Compromise multi‑agent systems The attack surface has expanded dramatically. What enterprises should do now 1. Constrain model permissions Limit what the model can do, not just what it should do. 2. Segment untrusted content Treat all external data -- including RAG sources -- as potentially hostile. 3. Monitor tool invocation Require human approval for high‑impact actions. 4. Validate content provenance Ensure RAG pipelines don't ingest poisoned external content. 5. Harden model routers Prevent attackers from forcing routing to weaker models. 6. Treat LLMs as untrusted components This mindset shift is the foundation of modern AI security. The bottom line Prompt injection remains the most effective way to compromise enterprise AI systems because it exploits the fundamental way LLMs interpret text. Until organizations treat LLMs as untrusted interpreters -- not autonomous decision‑makers -- prompt injection will continue to dominate the AI threat landscape. Julie Brunias is an AI Security Architect. Welcome to the VentureBeat community! Our guest posting program is where technical experts share insights and provide neutral, non-vested deep dives on AI, data infrastructure, cybersecurity and other cutting-edge technologies shaping the future of enterprise. Read more from our guest post program -- and check out our guidelines if you're interested in contributing an article of your own!

CrowdStrike warns prompt injection attacks hit over 90 firms in 2025

In its 2026 Global Threat Report, CrowdStrike reported prompt injection attacks at more than 90 organizations during 2025. The injected prompts generated commands that stole credentials and cryptocurrency, marking a significant shift as these prompts now function as malware. The report documented an 89% year-over-year rise in AI-enabled adversary operations. Additionally, 82% of intrusions involved no traditional malicious code, occurring as enterprises transitioned to using agents, copilots, and browser automations that access email, code, payments, and file shares. Prompt injection has maintained its top ranking as LLM01 on the OWASP Top 10 for large language model applications for two consecutive editions. OWASP highlighted that language models are unable to reliably distinguish developer instructions from untrusted text, transforming what was once a research curiosity into an operational vulnerability. Direct prompt injection takes place when a user types instructions to override a system prompt, while indirect prompt injection occurs when an attacker embeds instructions within content the model reads later, such as emails or documents. The user does not see the payload, and the agent executes the malicious commands without interaction. Two notable incidents shed light on the severity of these vulnerabilities. In August 2024, PromptArmor disclosed that a Slack AI attacker could exfiltrate data from private channels by planting instructions in public channels or uploaded files. The following year, Aim Security reported EchoLeak (CVE-2025-32711), where a crafted email directed Microsoft 365 Copilot to retrieve internal files and send them to an attacker-controlled server, achieving a CVSS score of 9.3. Both vulnerabilities were patched, but the class of attacks remains unresolved. The surface area of vulnerability has expanded to include a broader agentic stack, where agents that execute various tasks treat their context as authoritative. This development means long-term agent memory can retain and execute malicious instructions repeatedly. OpenAI acknowledged in December 2025 that prompt injection is unlikely to be fully solved, often likening it to social engineering. Anthropic's Claude Opus 4.6 system card indicated a 17.8% success rate for a single prompt injection attempt, escalating to 78.6% over 200 attempts without safeguards in place. Google reported a 53.6% success rate for prompt injection against its Gemini deployment. In December 2025, Gartner advised CISOs to block all AI browsers, citing indirect prompt injection and other risks associated with insufficient controls. Cyberhaven reported that 27.7% of organizations had at least one user with the blocked AI tool Atlas installed, a warning echoed by the UK National Cyber Security Centre and Germany's BSI. The limitations of existing defenses against prompt injection stem from the shared text channels in language models. Input validation, output filtering, and other detection methods struggle due to the inherent inability to separate authorized commands from untrusted content within the model. A separate finding indicated that 65.3% of organizations lack dedicated defenses against prompt injection, relying instead on vendor-supplied measures and policy training. Effective controls should include limiting each agent's authority, requiring human approval for critical actions, tagging retrieval sources based on sensitivity, and implementing auditing practices. As organizations consider AI deployments, security teams are encouraged to ask vendors about detection capabilities, success rates against prompt injections, adherence to OWASP recommendations, and the capacity to log exact agent actions. Given the vulnerabilities, it's critical for enterprises to assume that models may occasionally follow injected instructions, necessitating robust external controls.

Prompt Injection Attacks and Security Risks in LLM Apps

Join the DZone community and get the full member experience. Join For Free Everyone talks about model safety. Not enough people talk about what happens when the input itself is the weapon. Prompt injection is not a niche edge case. It is the most direct way to compromise an LLM application. And most teams are not ready for it. The model works exactly as designed. The attacker just rewrites the instructions. That is the gap. Not in the model. In how people build around it. The Pattern That Shows Up Again and Again * A chatbot deployed with no input validation and no output filtering. * A RAG pipeline fetching external documents. Nobody checked what those documents say. * A multi-agent system passing data between models. Each one trusting the last. * Credentials that never expire. Tokens scoped way beyond what the task needs. The injection succeeds not because the model is broken. Because nobody expected the input to fight back. The other thing worth saying early: this is not just a problem for large teams. A solo developer shipping a side project with a GPT backend is just as exposed. The model does not care how big your organization is. If you are accepting untrusted input and not validating output, you have a problem. What Prompt Injection Actually Is A prompt injection attack hijacks the model's instruction context. The attacker inserts text that overrides or contradicts the system prompt. The model cannot tell the difference. It processes attacker-controlled text with the same trust it gives to legitimate instructions. There are two main types. Direct injection is the simpler one. The user types something hostile straight into the input field. The model reads it, treats it as an instruction, and complies. Indirect injection is worse and harder to catch. The payload hides in content the model retrieves from somewhere else: a webpage, a PDF, an internal document in a RAG pipeline. The user is not even involved. They asked a normal question. Both types share the same root cause. The model has no reliable way to separate instructions from data. Everything arrives as text. Everything gets interpreted. Direct Injection A customer support bot is told to only answer billing questions. The attacker types this instead. Indirect Injection The user asks a normal question. The model fetches context from an external source. That source is where the attack lives. The user has no idea. Indirect injection is particularly dangerous because it removes the attacker from the picture entirely. They do not need access to your application. They just need to get their payload into a document your model might retrieve. A poisoned Wikipedia article. A crafted PDF uploaded to a shared drive. A webpage that ranks in search results. The attack surface extends to everything the model can read. Why Standard Defenses Miss This Traditional security knows its attack surface. SQL injection has parameterized queries. XSS has output encoding. Each problem has a known solution and a well-understood fix. Prompt injection does not work like that. The input is natural language. The model is built to interpret it flexibly. Ambiguity is a feature, not a bug. You cannot enumerate every possible hostile phrase because language has infinite variations. The attacker can rephrase, translate, encode, paraphrase, use metaphor, use analogy. The filter never sees the attack because the attack never looks the same twice. Most teams reach for keyword filtering first. Block certain words. Flag known phrases. It buys you something against unsophisticated attacks. But against anyone who knows what they are doing, it fails almost immediately. They base64-encode the payload and tell the model to decode it first. They write the instruction in French. They split it across multiple messages. The model reassembles it. The filter does not. What Does Not Work * Keyword filtering - Bypassed by rephrasing, encoding, or translation. * Prompt length limits - Indirect injections can be very short. * Safety training alone - Jailbreaks exist for every major model and are shared publicly. * Trusting retrieved content - It is untrusted by definition. * Assuming the model will refuse - It depends entirely on how the attack is framed. The model does not know it is being attacked. That is the whole problem. This is not a reason to give up on filtering. It is a reason to understand what filtering is actually for. It raises the cost of attack. It stops the opportunistic attacker who is not willing to adapt. It is one layer in a stack. Not the stack. Input Validation That Actually Helps You cannot filter natural language perfectly. That does not mean validation is pointless. It means you need to validate structure, not just content. The first thing to do is separate user input from system context. Never concatenate them into a single string and pass it straight to the model. The system prompt and the user message should be distinct, structured inputs. Enforce context boundaries. If a user is allowed to ask billing questions, the architecture should make it hard for their message to break out of that scope. The second thing is pattern matching. It is imperfect. Do it anyway. Block known trigger phrases. Set hard length limits. Reject inputs that match injection signatures. Log every rejection. Over time, the patterns tell you what people are trying. The RAG Pipeline Is an Attack Surface Retrieval-augmented generation is now standard practice. The model fetches live documents, uses them as context, and generates a response grounded in that content. It is a good pattern. It also introduces an attack surface that most teams have not thought carefully about. Every document your pipeline retrieves is untrusted input. It does not matter that the document came from your own storage bucket or a trusted third-party API. If someone can influence that document, they can inject into your model. And the list of people who can influence documents your model might retrieve is often much longer than the list of people who can reach your API. Think about a customer-facing application that retrieves product documentation. If those docs are stored in a shared system, anyone with write access to the docs has indirect injection capability. They do not need to know anything about your LLM stack. They just need to add one hidden line to a document. The sanitization above is a start. It is not complete. You should also validate that retrieved content is actually about what you asked for. If you fetched a page about billing and the retrieved text is talking about system configuration, something is wrong. Semantic validation is harder to implement, but it catches things pattern matching cannot. The other practical step is limiting what the model can retrieve in the first place. Do not give it access to your entire document corpus if only certain documents are relevant to the task. Scope the retrieval. Narrow the search space. The attacker can only inject through documents the model can actually reach. Output Monitoring for Exfiltration Input validation catches attacks before they reach the model. Output monitoring catches what got through anyway. Every model response is a potential exfiltration event. A successful injection usually changes what the model says. It reveals things it should not reveal. It takes actions it should not take. It produces content way outside its intended scope. If you are not checking the output, you will not know this happened until a user complains or an auditor finds it. The checks you need at minimum are simple. Look for PII the model was never supposed to handle. Look for fragments that look like system prompt content. Look for responses that are dramatically longer or shorter than normal. Look for content in a completely different topic area from what was asked. None of these are perfect signals, but they are all meaningful. There is a second category of output check that is easy to overlook: scope validation. The model might produce a response with no PII and no leaked system prompt and still be doing exactly what the attacker wanted. If the billing bot starts writing code, that is a scope violation. If the customer support assistant starts giving medical advice, that is a scope violation. Define what normal output looks like for your application and flag anything that does not fit. Output monitoring also gives you something you cannot get from input logs alone: evidence. If something goes wrong and you need to understand what the model said, when, and to whom, output logs are how you reconstruct it. Build them from day one. Multi-Agent Systems Make This Worse One model is a risk you can reason about. A pipeline of models is a different problem entirely. The output of the first becomes the input of the second. A successful injection at step one does not just affect step one. It propagates. By step three, the attacker's instruction has been processed by two intermediate models and looks completely legitimate. No model in the chain raised a flag. They were all just doing their jobs. This is not a hypothetical concern. Multi-agent architectures are the direction everything is moving. Research assistant agents that spawn subagents. Coding tools that call out to documentation agents and then testing agents. Customer service workflows with a routing model, a response model, and a compliance check model. Each hop is a potential amplification point. The fix is the same as the input validation fix, applied at every boundary. Treat the output of one model as untrusted input to the next. Do not assume that because something passed a check at step one, it is clean at step two. Check at every handoff. There is a practical tension here. More checks mean more latency. Every gate adds round-trip time. In a real-time application, that matters. The answer is not to skip checks but to make them fast. Lightweight pattern matching and PII detection run in milliseconds. Reserve the expensive semantic checks for high-stakes handoffs. Profile your pipeline and understand where the actual cost sits before deciding what to cut. Least Privilege for AI Agents The most dangerous LLM applications are not the ones with the weakest input validation. They are the ones with too much access. A model that can read files, send emails, call APIs, write to databases, and browse the web does serious damage when compromised. And it will be compromised eventually. The question is what happens next. Least privilege applies to AI agents exactly as it applies to service accounts and microservices. Give the model the minimum access it needs to complete its task. Nothing more. If the billing assistant does not need to read customer conversation history, it does not get access to customer conversation history. If the research agent only needs to search the web, it does not get file system permissions. This is not about distrusting the model. It is about containing the blast radius when something goes wrong. A successfully injected model with read-only access to one database table is a much smaller incident than a successfully injected model with write access to your entire infrastructure. Credential rotation matters here too. Token-based access that never expires is a problem for every system. For LLM agents, it is a bigger problem because the tokens are often embedded in prompts or passed as context, which means they can be exfiltrated. Short-lived credentials that are scoped tightly and rotated frequently limit what an attacker can do even if they get hold of one. The other thing worth building is a tool registry. Know every capability your model has access to, who approved it, and why. When someone asks why the billing bot has file write permissions, you should be able to answer immediately. If you cannot, that is a governance gap. Prompt Versioning Is Not Optional Most engineering teams version their code. Almost none version their prompts. That is a governance failure with real consequences. The system prompt defines what your model does. Change it without tracking the change, and you have no idea what you shipped. Change it without testing it, and you have no idea if the change introduced a new attack surface. Change it without review, and you have no accountability. You might as well be editing production code directly in the database. Prompt versioning is not complicated. It is the same discipline you apply to code: draft, test, review, merge, deploy, with rollback available. The tooling does not need to be elaborate. What matters is that every change is tracked, tested against known edge cases and adversarial inputs, and reversible if something goes wrong. The testing step is where most teams skip ahead. They write a new prompt, try it manually a few times, and ship it. That is not enough. You need automated tests that cover the expected behavior, the edge cases, and the adversarial cases. What happens when someone tries to inject through this prompt? Does the new version handle it better or worse than the old one? You need to know before it goes live. Rollback is the other piece. If something goes wrong after a prompt change, how quickly can you revert? If the answer is anything longer than a few minutes, that is too slow. Build the rollback path before you need it. Logging Is Evidence Most injection attacks surface in the post-mortem. The alert did not fire. The monitor missed it. The user noticed something strange and filed a support ticket three days later. But the log had everything the whole time. Build structured audit logging from day one. Every inference request. Every tool call. Every output that triggered a check. Every prompt version that was active at the time. Every credential that was in scope. You cannot investigate what you did not record. In regulated environments, you cannot prove compliance without it either. Structured logging matters as much as logging itself. If your logs are free-text strings, you will spend half your investigation time parsing them. JSON, consistent field names, timestamps in UTC, task IDs that thread through the whole request lifecycle. These are not nice-to-haves. They are what make the logs usable when you need them most. One thing worth thinking about early: log retention and access. Who can read the logs? Are they tamper-evident? If an attacker compromised your model and also had access to your log store, could they cover their tracks? These questions feel paranoid until you are in a post-incident review trying to prove what happened. Think about them now. Red Team It Before Someone Else Does Everything above is defensive. You validate inputs. You sanitize retrieved content. You check outputs. You gate every handoff. You log everything. That is the foundation. Red teaming is what you do to find out whether the foundation actually holds. It is adversarial testing: you try to break your own application the same way an attacker would. You craft injection attempts. You try to exfiltrate the system prompt. You attempt to escalate privileges through the model. You try every jailbreak framing you know about and several you invent on the spot. The goal is not to break your application for fun. The goal is to find the gaps before a real attacker does. Every failure in a red team exercise is a gap you can close. Every failure in production is an incident you have to manage. Red teaming should be on a cadence, not just at launch. Every significant prompt change warrants a targeted red team run. Every new tool or capability added to the model warrants one. Every time you expand the scope of what the model can do, you have expanded the attack surface too. If your team does not have security expertise in-house, bring in someone external who does. A fresh perspective finds things internal teams miss. The cost of a professional red team exercise is small compared to the cost of a real incident. Defense in Depth No single control stops prompt injection. That is the uncomfortable truth. The attack surface is the natural language interface itself, and you cannot close it without removing the model. What you can do is layer your defenses so that each layer catches what the previous one missed. Input sanitization catches known patterns. Structural isolation limits what a successful injection can do. Output monitoring catches what got through anyway. Audit logging catches what the monitor missed. Least privilege contains the damage even when everything else failed. If one layer fails, the next one is already running. The layers interact in ways that matter. Input validation and output monitoring together give you a view of what the model received versus what it produced. That gap is where injections live. Logging and red teaming together tell you whether your defenses are actually working or whether they just look like they are working. Least privilege and prompt versioning together mean that even a successful attack has a limited blast radius and a clean paper trail. The Full Stack * Validate inputs. Pattern matching, length caps, schema enforcement. * Sanitize retrieved content. Treat every external document as hostile. * Isolate context. System prompt and user input are never in the same trust zone. * Check outputs. PII detection, scope validation, system prompt leak detection. * Gate every agent handoff. No unvalidated output passes between models. * Enforce least privilege. Each agent accesses only what it needs. * Version prompts. Every change tested, reviewed, and reversible. * Log everything. Structured, timestamped, tamper-evident. * Red team on a cadence. Not just at launch. The model does not defend itself. You defend it. This Does Not Have a Close Date Security risks in LLM applications are still not well understood in industry. Most teams ship the model and move on. Nobody reviews the prompts after go-live. Nobody monitors the outputs consistently. Nobody tests what happens when the inputs are hostile. The security review that happened before launch is treated as permanent clearance. It is not. The threat landscape changes. Attackers share jailbreaks publicly. New injection techniques get published. Your own application evolves: new features, new tools, new documents in the RAG corpus, new agents in the pipeline. Each change potentially opens a new angle. The teams that stay ahead of this are not the ones with the most sophisticated tooling. They are the ones who treated security as a process rather than a checkpoint. Regular reviews. Regular red teaming. Monitoring that runs continuously, not quarterly. Someone whose job it is to keep watching even after the launch celebration is over. That is not glamorous. It is just how security works. Start with input validation. Add output monitoring. Build the audit trail. Then red team it before someone else does.