Your Resume Is Also a Prompt: Why Prompt Injection Is the Defining Security Problem in Real-World LLM Systems

A 2025 RecSysHR paper studied resumes containing hidden adversarial instructions designed to make an LLM overrate a candidate. The authors report seeing real examples in which job seekers hid manipulative text in very small white font, and they evaluated defenses across 1,200 experiments, spanning 10 injection strings, 5 models, and 24 prompting and defense setups. That paper is nominally about hiring. It is not really about hiring. It is about a much bigger architectural truth: when an LLM reads untrusted content, the channel that carries data and the channel that carries instructions become the same channel. NIST explicitly describes this in retrieval systems, noting that LLM use has "blurred the data and instruction channels," which enables indirect prompt injection attacks. This is the core issue. Not resumes. Not HR. The issue is that language has become both the input medium and the control surface.

Microsoft frames indirect prompt injection in practical enterprise terms: it happens when an LLM processes untrusted data and mistakes attacker-controlled content for instructions. Their July 2025 guidance describes this as a growing problem in enterprise workflows and emphasizes layered defenses, including input isolation, detection, and impact mitigation. OpenAI has made a similar point: prompt injection is a "frontier security challenge," and in agentic systems the goal is not merely to detect every malicious input, but to constrain the impact even when manipulation attempts succeed. This shift in framing is important. For a long time, people discussed prompt injection as if it were mostly a prompting problem. It is not. It is a systems problem.

The RecSysHR paper measured jailbreak success rates across models with the same mitigation strategies applied. Averaged across defenses, the results were striking: o4-mini at 0.8%, gpt-4.1 at 9.6%, o3-mini at 20.8%, gpt-4.1-nano at 48.7%, and gpt-4.1-mini at 52.1%. This matters because many enterprise teams still evaluate models mostly on quality, latency, and price. They should also be evaluating security behavior under adversarial conditions. The paper also found that defense design can radically change outcomes. With the best-performing mitigation, gpt-4.1-mini dropped from 52.1% jailbreak success to 0.0%. By contrast, several no-guardrail strategies reached 54.0% jailbreak success. That is the difference between "unsafe by default" and "possibly viable with careful architecture."

One of the strongest results in the HR paper came from a setup that did three simple things: put the untrusted content in its own message boundary, labeled it explicitly as untrusted, and added a jailbreak-detection guardrail instructing the model how to interpret it. The best-performing strategy was the user-with-jailbreak-detection-guardrail-and-untrusted-tag-close configuration, achieving a 4.0% average jailbreak success rate. This aligns strongly with Microsoft Research's Spotlighting work. That paper argues that indirect prompt injection becomes possible because multiple input sources get flattened into one text stream, and it proposes provenance-signaling transformations so the model can distinguish trusted from untrusted sources. In their experiments, Spotlighting reduced attack success from above 50% to below 2% with minimal task impact. Different paper, same direction: make trust boundaries explicit.

The resume example is just the most legible one. The same underlying failure mode appears anywhere an LLM reasons over untrusted material: support tickets, emails, PDFs, CRM notes, web pages, RAG chunks, tool outputs, browser environments, multimodal interfaces. NIST's taxonomy discusses indirect prompt injection in RAG and notes that such attacks can lead to availability violations, integrity violations, privacy compromise, and abuse violations. The broader pattern also shows up in agent benchmarks. InjecAgent introduced 1,054 test cases spanning 17 user tools and 62 attacker tools, and reported that tool-integrated LLM agents were meaningfully vulnerable, with ReAct-prompted GPT-4 compromised 24% of the time. AgentDojo pushes this further with 97 realistic tasks and 629 security test cases in a dynamic environment. VPI-Bench extends the concern into computer-use and browser agents, with 306 test cases showing that malicious visual instructions can manipulate agent behavior.

One of the most important implementation lessons in the HR paper is that the tested application already used structured output to force the model into a machine-readable mapping from criteria to scores. It also experimented with different message placements, including tool-message patterns. Yet weak configurations still failed badly. This aligns with what many teams see in production: a model can return valid JSON and still be wrong for adversarial reasons. The parser may be happy. Your security team should not be. The distinction that matters is this: schema compliance is not semantic integrity. A model that returns well-formed JSON with manipulated scores is not giving you safety — it is giving you false confidence.

Another reason this area deserves deeper attention is that the research is moving beyond "better prompts" and toward architectural control. A 2024 paper on f-secure LLM systems argues for a system-level defense grounded in information flow control. The idea is to separate planning and execution, filter untrusted input before it can influence high-trust planning steps, and reason about security properties at the system level rather than inside a single giant prompt. OpenAI's recent guidance on agent design makes a similar move: constrain risky actions, protect sensitive data, and design systems so that successful manipulation attempts do not automatically translate into damaging outcomes. Microsoft's enterprise guidance reflects this shift with five defense layers. This is where the field is maturing: from "How do I write a better system prompt?" to "How do I build a system where the model has fewer opportunities to do the wrong thing?"

When I look at LLM failures in the wild, many of them are really failures of boundary design. Who gets to issue instructions? Which channels are trusted? What happens when content and commands look identical? Can retrieved text influence planning? Can tool output influence authorization? Can the model turn untrusted content into actions? These are not cosmetic UX questions anymore. They are security questions. The best LLM systems in the next few years will not just be the ones that reason well. They will be the ones that know who is allowed to influence that reasoning, and how much.

If I were reviewing an enterprise LLM workflow today, these would be the first questions I would ask. First, treat all external content as potentially adversarial — not just suspicious content, but all content. Second, separate channels by trust level so system policy, developer instructions, retrieved content, user uploads, and tool outputs are not blended into one flat context. Third, mark untrusted content explicitly with tags or provenance signals. Fourth, benchmark for robustness, not just task quality — if one model is at 0.8% and another is at 52.1% under attack, cost-per-token is not the only number that matters. Fifth, assume structured outputs are format controls, not truth controls. Sixth, add system-level constraints around actions and data access. Seventh, evaluate with attack suites like InjecAgent, AgentDojo, and VPI-Bench, not only happy-path evaluations.

I do not think prompt injection is an edge case. I think it is the price we pay for building systems that interpret natural language flexibly across mixed-trust environments. That does not mean LLM products are doomed. It means we need to stop pretending that security lives only in the model. Some of it lives in the model. A lot of it lives in the architecture. And an uncomfortable amount of it lives in what looks, on the surface, like simple interface design. The best LLM systems in the next few years will not just be the ones that reason well. They will be the ones that know who is allowed to influence that reasoning, and how much.

These references span the academic research, industry guidance, and standards that inform this analysis. They represent the current state of understanding on prompt injection as both a technical problem and a systems architecture challenge.