Prompt Injection Against LLM-Integrated SaaS Features

Prompt injection against LLM-integrated SaaS features exploits the same ability that makes an assistant useful, which is following instructions in text. The responsible response is to limit what a hijacked agent can do and test every route by which outside content can influence it, including the chat box.

Why LLMs cannot separate instructions from data, and why that gap is not fixable by configuration

SQL injection offers a useful starting point. A system treats data from an attacker as instructions, which gives the attacker a say in what happens next. Liu et al. describe this confusion in HOUYI as persuading a model to interpret a malicious payload as a question. But the analogy has a limit. With an LLM, the parser is a reasoning system that cannot enforce a reliable boundary between commands and content.

The model processes its input as a single token stream, so it cannot reliably distinguish developer instructions from attacker-supplied text. Instruction-following itself is the feature being exploited. This is not missing validation on a form field, and patching one component cannot remove the attack surface. Sanitization can help at the margins, but the model still has to read and act on the content it receives. A delimiter or format does not turn that content into something the model can no longer mistake for authority.

How direct and indirect injection differ, and why indirect injection is the more dangerous path in SaaS products

Direct injection starts with an attacker using the application. They type adversarial instructions into the chat input and try to redirect the model away from its intended task. The attacker is also the user. Their scope is bounded by what that user is permitted to do, making the chat interface an obvious place to test. That visibility distinguishes it from the less obvious route through content the application retrieves.

Indirect injection does not require an attacker account, session, or direct channel to the model. Instead, instructions arrive inside an email, document, web page, retrieval result, or tool output that the agent fetches for a legitimate user. The user may ask only for an email summary. If that email contains an injected instruction, the agent can encounter the attack while performing exactly the task it was given. Liu et al. describe this pattern in their universal prompt injection research, where a modified external resource steers the model toward a predetermined response without the user knowing that the instruction came from an adversary.

That makes indirect injection the more dangerous path in SaaS products. A RAG pipeline can retrieve a poisoned document, just as a browsing agent can fetch a page containing a hidden payload. Every external source reachable by the agent is a potential vector, so integrations expand the attack surface even when the product’s own code changes little.

What attack paths open when an LLM is connected to tools, APIs, and external data

Consider a possible attack chain in which an assistant reads an email containing malicious instructions and then uses an available tool to send out data. Its severity depends on the assistant’s permissions. An injection against a text-only feature has different consequences from one against an agent allowed to query databases, make network requests, or execute commands. The injected text is the entry point, while the tool stack determines how far the attack can go.

Spiros Tsigkopoulos and Christoforos Ntantogian describe these paths as LLM-mediated web attacks, organized under an LLM2X taxonomy. The model acts as a mediation layer, or a confused deputy, letting the attacker reach components that trust model-generated content. In LLM2SQLi, generated or modified SQL reaches the database layer. In LLM2CommandInjection, model-built tool arguments reach a command-execution component such as an MCP server. The same pattern connects model influence to network requests through LLM2SSRF and to cross-site scripting through LLM2XSS.

These are familiar vulnerabilities with a new delivery route. The model can expose an underlying flaw through an operational interface that engineers may have treated as conversational. In a multi-agent system, the influence can also spread through shared context, message buses, or delegation protocols. At each handoff, trust is again at stake because a downstream agent may get attacker-influenced content from what looks like a legitimate colleague.

RAG pipelines and agent skill files as injection vectors distinct from the chat interface

RAG poisoning attacks the retrieval corpus. An attacker inserts crafted documents that the agent may later retrieve for an ordinary request. Once retrieved, their instructions can corrupt the answer or cause unintended actions. The attacker never has to address the assistant directly. Testing the chat interface therefore says little about whether the retrieval pipeline can promote untrusted document text into instructions.

For multi-tenant SaaS, retrieval boundaries make this especially serious. A document uploaded by one tenant could influence an agent serving another tenant if separation is not enforced at the data layer. That creates a cross-tenant injection path. This risk depends on the retrieval architecture used for RAG. It is nevertheless a distinct assessment question because the source of the attack and the user affected by it can belong to different tenants.

David Schmotz et al. identify third-party skills as a supply-chain attack surface in SKILL-INJECT, where the agent can execute malicious instructions while the user sees only the advertised function. Their benchmark reports attack success rates up to roughly eighty percent across frontier models, with harms that include data exfiltration and file operations that destroy files. Here, the file is supposed to contain instructions. Malicious content can therefore be structured in the same way as legitimate skill content, and contextual, dual-use injections were still dangerous even with warning prompts. Both skills and RAG documents can reach the agent without the attacker having an account in the application, but tests must account for what each is meant to do.

Why current defenses reduce blast radius but cannot close the structural gap

Input filtering, instruction hierarchy, fine-tuning, and prompt engineering defenses can reduce exposure. None of these defenses can reliably stop attacks. A team of researchers propose turning attack techniques into a defense by repeating the injection process with the original instruction to override injected content. It still operates through the same instruction-following behavior the attacker is trying to exploit.

The strength of a defense also depends on how it is tested. The universal prompt injection research shows that automated gradient-based attacks can circumvent defensive measures with very few training samples. Defenses need to pass more than a set of manual prompts. Similarly, the skill benchmark concludes that model scaling and simple input filtering are insufficient, and calls for context-aware authorization frameworks. A model that follows legitimate instructions must remain responsive to text, which creates an inherent tension for defenses that work only by changing how that text is presented.

The practical response is containment through least privilege. Tool permissions should be scoped to each agent’s role so that a successful injection has a bounded blast radius. Other useful controls include provenance labels on retrieved content, separation of retrieval results from instruction context where possible, and output validation before tool calls execute. These controls protect different points in the chain. They do not all depend on the model recognizing an attack correctly.

Tsigkopoulos and Ntantogian show that susceptibility varies across models but is rooted partly in the surrounding application architecture. A model that behaves better can lower risk while leaving an unsafe tool-call path or a broken retrieval boundary in place. The engineering task is therefore broader than choosing a model or strengthening a system prompt. It includes deciding which actions the application will permit even when the model has been misled.

What a security assessment of LLM-integrated features actually needs to cover

A thorough assessment covers five distinct surfaces, which are input/output, retrieval, agentic/tool-call behavior, the model layer, and runtime infrastructure. Chat-only testing is equivalent to reviewing a login form and calling the application assessed. It misses retrieval corpus integrity, tool authorization, cross-agent trust, and the skill supply chain. It also misses infrastructure reachable through LLM2SSRF or LLM2CommandInjection paths. HOUYI tested 36 real LLM-integrated applications and found the majority susceptible to prompt injection, placing this exposure beyond research benchmarks.

Access determines what a tester can establish. Black-box testing can validate external exposure, but without visibility into retrieval and tool calls, it cannot reveal every authorization failure behind an answer. Grey-box access to architecture diagrams and logs is typically the minimum for a meaningful assessment. Privileged agents need both white-box review and active testing. Source code, cloud configurations, tool definitions, and retrieval architecture let testers map attack paths at scale and check whether the component that receives model-generated parameters validates them before it acts on them.

The assessment also needs to connect reconnaissance to consequences. System prompt extraction is standard reconnaissance, using direct requests, role-play framings, and token-boundary probes. Partial leakage can reveal enough architecture detail to sharpen later attacks. Probe-based scanners and multi-turn attack simulators can find easier weaknesses quickly, but testing indirect injection means following a chain through retrieval, tool use, and output. Manual expert testing remains necessary for the highest-risk paths because automated tooling alone cannot replicate that contextual reasoning.

Working exploits distinguish an actionable finding from a possibility. A report that suggests LLM2SSRF without exercising the actual tool stack does not tell engineers whether an internal metadata endpoint is reachable. Repeated testing is equally important because model behavior is probabilistic. A moderate success rate across invocations is not well described by a deterministic CVSS score alone. Reports need to record success rates as both a severity factor and a baseline for judging remediation.

Audit evidence needs the same specificity. ISO 27001 Annex A 8.29 calls for security testing during development and acceptance, while SOC 2’s CC4.1 and related CC7.1 give testing evidence a place in an audit. CC7.1 concerns detecting and monitoring vulnerabilities, with no explicit mandate for security testing. Neither framework supplies a method for assessing an LLM agent, so the test vendor must make that method clear. An auditor cannot evaluate coverage that the report leaves unstated.

How to integrate LLM security testing into the development lifecycle rather than treating it as a one-time exercise

An annual penetration test cannot cover changes made after it. Each new tool, connector, retrieval corpus, or agent skill changes what the model can encounter or do. The testing cadence should follow those changes. Teams can assess architecture, trust boundaries, and high-risk tool paths on an annual or semi-annual basis to set a baseline, then retest the affected paths whenever those additions ship. Continuous pull-request scanning can then flag prompt-template changes and new tool-call sinks as they are committed.

Skills need close review before release because installing them brings third-party instructions into the agent’s trust boundary. The skill research treats this as the new package installation. That boundary should be validated before a skill reaches production, rather than waiting for the next scheduled assessment. Catching an unvalidated tool-call sink during review is cheaper than discovering it in a post-release penetration test.

Alongside a code check, remediation needs a behavioral test that reruns the same attack scenarios and establishes whether their success rate has dropped. A changed prompt template is not proof of a fix. Because LLM2SQLi and LLM2SSRF reach familiar application components through a new delivery path, this work belongs within the existing application security program. The program should cover the LLM layer too, rather than treating it as a separate feature judged safe because the chat box gives reassuring answers.