<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>hackerlogs: Prompt Injection &amp; Jailbreaks</title>
    <link>https://hackerlogs.com/topics/prompt-injection</link>
    <atom:link href="https://hackerlogs.com/topics/prompt-injection/rss.xml" rel="self" type="application/rss+xml" />
    <description>Direct and indirect prompt injection, jailbreak techniques, and the defences that actually hold up under adversarial pressure.</description>
    <language>en</language>
    <lastBuildDate>Thu, 03 Sep 2026 00:00:00 GMT</lastBuildDate>
    <item>
      <title>Build an Indirect Prompt Injection Lab in Thirty Minutes</title>
      <link>https://hackerlogs.com/blog/indirect-injection-lab</link>
      <guid isPermaLink="true">https://hackerlogs.com/blog/indirect-injection-lab</guid>
      <pubDate>Thu, 03 Sep 2026 00:00:00 GMT</pubDate>
      <dc:creator>Ajain Vivek</dc:creator>
      <description><![CDATA[<p>An indirect prompt injection lab needs three parts: a retriever that fetches attacker-controlled text, a model that treats retrieved text as instructions, and a tool the model can call to prove impact. Build all three locally with a poisoned document, a small model, and a fake exfiltration endpoint, then replay one payload against each defence to see which hold.</p><p><strong>Key takeaways</strong></p><ul><li>Reading about indirect injection convinces nobody; a working demo against your own stack ends the argument in one meeting.</li><li>The lab needs a side effect, not just a rude answer, because impact is what turns a demo into a funded remediation.</li><li>Run the identical payload against each defence in turn, so you measure the control rather than your own improvisation.</li><li>Input filtering blocks your first payload and fails against the second, which is the point the lab exists to make.</li><li>Removing the model's ability to reach the network changes the outcome where prompt hardening does not.</li></ul>]]></description>
      <category>prompt-injection</category>
      <category>ai-red-teaming</category>
    </item>
    <item>
      <title>Prompt Injection: Why There Is No Patch, and What Actually Reduces Risk</title>
      <link>https://hackerlogs.com/blog/prompt-injection-no-patch</link>
      <guid isPermaLink="true">https://hackerlogs.com/blog/prompt-injection-no-patch</guid>
      <pubDate>Tue, 01 Sep 2026 00:00:00 GMT</pubDate>
      <dc:creator>Ajain Vivek</dc:creator>
      <description><![CDATA[<p>Prompt injection is an attack where untrusted text reaching a language model is interpreted as instructions rather than data. Because models process instructions and content in the same token stream, there is no reliable syntactic boundary between them. Defences reduce blast radius through privilege separation and output handling rather than filtering malicious phrasing.</p><p><strong>Key takeaways</strong></p><ul><li>Prompt injection is an architectural consequence of how transformers consume text, not a bug that a vendor can patch.</li><li>Indirect injection, where the payload arrives through retrieved documents or tool output, is the variant that matters for real applications.</li><li>Input filtering fails because the space of adversarial phrasings is unbounded; treat it as telemetry, never as a control.</li><li>The defences that hold are architectural: least privilege on tools, human confirmation on side effects, and treating model output as untrusted.</li><li>OWASP ranks prompt injection as LLM01, the top risk in its Top 10 for LLM Applications.</li></ul>]]></description>
      <category>prompt-injection</category>
      <category>llm-app-security</category>
    </item>
  </channel>
</rss>
