Design Patterns for Securing LLM Agents against Prompt Injections · HackerPapers discussions

Design Patterns for Securing LLM Agents against Prompt Injections — mentioned by mattalex

Sat, 04 Jul 2026 19:10:59 GMT

You can get rid of 99.9% of those attacks by simply dispatching the data consumption to a different instance of the LLM, see, for instance, some of the later patterns in https://arxiv.org/abs/2506.08837

Paper and discussion history. A mention is not an endorsement.

Design Patterns for Securing LLM Agents against Prompt Injections — mentioned by amonks

Thu, 04 Sep 2025 23:03:36 GMT

That’s a pretty scary answer, to be honest. Regardless, here’s the CaMeL paper. Defeating Prompt Injections by Design (2025): https://arxiv.org/abs/2503.18813 Here’s a paper offering a survey of different mitigation techniques, including CaMeL. Design Patterns for Securing LLM Agents against Prompt Injections (2025): https://arxiv.org/abs/2506.08837 And here’s a high-level overview of the state of prompt injection from 'simonw (who coined the term), which includes links to summaries of both papers above: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

Paper and discussion history. A mention is not an endorsement.

Design Patterns for Securing LLM Agents against Prompt Injections — HN submission

Sun, 10 Aug 2025 21:59:40 GMT

Design Patterns for Securing LLM Agents Against Prompt Injections

2 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Design Patterns for Securing LLM Agents against Prompt Injections — HN submission

Sun, 10 Aug 2025 13:29:31 GMT

Design Patterns for Securing LLM Agents Against Prompt Injections

2 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Design Patterns for Securing LLM Agents against Prompt Injections — HN submission

Sun, 10 Aug 2025 03:46:47 GMT

Design Patterns for Securing LLM Agents Against Prompt Injections

14 points; 2 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Design Patterns for Securing LLM Agents against Prompt Injections — mentioned by benlivengood

Sat, 09 Aug 2025 19:20:42 GMT

I believe you've covered some working solutions in your presentation. They limit LLMs to providing information/summaries and taking tightly curated actions. There are currently no fully general solutions to data exfiltration, so things like local agents or computer use/interaction will require new solutions. Others are also researching in this direction; https://security.googleblog.com/2025/06/mitigating-prompt-in... and https://arxiv.org/html/2506.08837v2 for example. CaMeL was a great paper, but complex. My personal perspective is that the best we can do is build secure frameworks that LLMs…

Paper and discussion history. A mention is not an endorsement.

Design Patterns for Securing LLM Agents against Prompt Injections — mentioned by simonw

Wed, 09 Jul 2025 03:27:32 GMT

There's a crucial difference here. When you were working as a pentester, how often did you find a security hole and report it and the response was "it is impossible for us to fix that hole"? If you find an XSS or a SQL injection, that means someone made a mistake and the mistake can be fixed. That's not the case for prompt injections. My favorite paper on prompt injection remedies is this one: https://arxiv.org/abs/2506.08837 Two quotes from that paper: > once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential…

Paper and discussion history. A mention is not an endorsement.

Design Patterns for Securing LLM Agents against Prompt Injections — HN submission

Tue, 08 Jul 2025 21:58:02 GMT

Design Patterns for Securing LLM Agents Against Prompt Injections

3 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Design Patterns for Securing LLM Agents against Prompt Injections — mentioned by mooreds

Fri, 13 Jun 2025 14:28:58 GMT

Also here's the referenced paper: https://arxiv.org/abs/2506.08837

Paper and discussion history. A mention is not an endorsement.