├── LICENSE └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 🛟 Prompt Injection Mitigations 2 | 3 | A comprehensive collection of prompt injection mitigation techniques, literature, and software suites. \(Rough draft\) 4 | 5 | # ⚠️ But First, A Few Words of Warning... 6 | 7 | These mitigation techniques should be a last resort, never to be heavily relied on or treated as a catch-all. They will fail. 8 | 9 | > “At a broader level, the core issue is that, contrary to standard security best practices, ‘control’ and ‘data’ planes are not separable when working with LLMs.” - [Rich Harang](https://www.linkedin.com/in/richharang/), Principal Security Architect (AI/ML) @ NVIDIA 10 | 11 | My own (less technically elegant) explanation: 12 | 13 | > "We have allowed the user input to be the trust boundary. It's the equivalent of offering the attacker remote code execution and then trying to parse the code to make sure it doesn't do anything bad. Except the code has no syntax rules. That's absurd." - [Jonathan Todd](https://www.linkedin.com/in/jonathanktodd/) (me), [*The Prompt Injection Mitigation Problem is Never Going Away.*](https://www.linkedin.com/pulse/prompt-injection-mitigation-exercise-futility-jonathan-todd) 14 | 15 | *"Prompt Injection Mitigation is Futile."* That might seem like a strong statement coming from someone compiling a list of mitigation techniques, but I think it's extremely important that we stress this truth to all software engineers. These mitigations are not fix-alls. The only safe way to handle untrusted user input passed to an LLM is to not trust the output. Consider the output to be toxic waste, only ever to be allowed to impact the user who prompted it or their trusted group. 16 | 17 | It is possible that the mitigations outlined here might prove to be robust. *Perhaps.* 18 | 19 | But if software engineers allow that resulting perception of safety to be the primary defense mode of their applications rather than doing the harder work of adhering to clear trust boundaries in their code, the software supply chain will suffer for it sooner or later. And since the mitigations will be packaged into a few distinct software suites and re-used by countless projects, a single clever mitigation bypass technique will result in widespread exploitation, similar to the Log4Shell security crisis. 20 | 21 | And besides those considerations, many of these mitigations come with significant time and cost trade-offs. You want to avoid leveraging them in your product if you can help it. 22 | 23 | --- 24 | 25 | # 🏰 The "Many Walled Gardens" Solution 26 | 27 | In most LLM use-cases, it is feasible to side-step any need for injection mitigations by "walling off" program states tainted by untrusted I/O. In other words, software should be designed in such a way that the only users that could be affected by their own input are themselves or users who've established trust relationships with them. 28 | 29 | That said, there are certain use-cases where this is less straight-forward: 30 | 31 | - **The Poisoned Well Problem:** Input thought to be trusted might have inadvertently become tainted. For example, perhaps a user sets their username to a prompt injection attack. Untrusted input, sure, but somehow, maybe via a reporting process, their info is attached to an email. Somehow that becomes a PDF. Incidentally, that file gets absorbed into your org's internal vector database. And finally, your org deploys an LLM-integrated system internally to explore that database for data categorization or processing or whatever the case may be. Now you're exposing a potentially privileged LLM-integrated application to a poisoned data source incorrectly assumed to be trustworthy. 32 | 33 | - **The Assistant Dillema:** Your team wants to develop an LLM-integrated autonomous AI assistant. This assistant is highly robust. It can write and execute code for the user. It can schedule appointments and make purchases on their behalf. It can log into and control their online accounts. The user asks it to browse the web to find something. It encounters a poisoned search result and poof. Pwned. 34 | 35 | These scenarios aren't as incredibly bleak as they might initially appear. Before relying on prompt injection mitigation techniques, the software engineer can deploy sub-sandoxes. Walled gardens within the walled garden. Put simply: The potentially tainted LLM prompt outputs can be used in a limited way, but not trusted. Not allowed to influence sensitive actions. 36 | 37 | Therefore, these mitigations should really just be a matter of: 38 | 39 | - **Quality Control**: Protect the user from being shown an inappropriate output triggered by some poisoned assets their AGI assistant encountered on the web. 40 | 41 | - **Defense in Depth**: If we assume software engineers will sometimes fail to fully sandbox untrusted I/O in LLM-integrated applications (and they will), depending on the risk involved, it might be prudent in certain use-cases to deploy these mitigation techniques. 42 | 43 | --- 44 | 45 | # 🛡️ Layered Defense 46 | 47 | Each technique listed in this document will be susceptible to bypass, but by layering many of them we convolute and add complexity to the attacker's search space of possible bypasses in the hope of reaching successful mitigation. Multi-layered defense is nothing new in the cybersecurity realm, but it's particularly prevalent here due to the fundamentally unsolvable nature of the problem. The only hope of success in the LLM prompt injection mitigation endeavor is to combine many of these techniques. 48 | 49 | --- 50 | 51 | # 📘 Techniques 52 | 53 | ## 💬 Paraphrasing 54 | Ask an LLM to paraphrase the prompt while retaining as much detail as possible. Although the injection attack may attempt to trick the paraphrasing step into echoing the initial message, the sophistication required for this could potentially conflict with any subsequent injection strategies. 55 | 56 | `🔁 Active` `📤 Output-focused` `🌐 Generic` `🤖 Automated` `⚡ Low Time Overhead` `💲 Low Cost` 57 | 58 | 59 | ## 🕵️‍♂️ Threat Intel Driven Sanitization 60 | Based on threat intel, use string searches, vector databases, and embeddings to match known injection techniques. Upon detection of similar strings, remove them from the prompt. 61 | 62 | `🔁 Active` `🛡️ Preventive` `📥 Input-focused` `🔬 Specific` `👥 Manual` `⚡ Low Time Overhead` `💰 High Cost` 63 | 64 | 65 | ## 🧬 Mutation & Repair 66 | Leverage the often incoherent nature of prompt injection strings against the attacker. Randomly remove characters from the input prompt and use an LLM to correct any errors in the text. Repeat this process N times. Start this process in parallel multiple times. After sufficient iterations, the repaired portions of a prompt might lose any obscure, likely-to-be injection-related details. 67 | 68 | `🔁 Active` `🛡️ Preventive` `📥 Input-focused` `🌐 Generic` `🤖 Automated` `🕰️ High Time Overhead` `💰 High Cost` 69 | 70 | 71 | ## 🔍 Relevance Filtering 72 | Many injection attacks involve odd and seemingly irrelevant strings of text. Use an LLM to divide up the content of the prompt into a list of details and assess each item's relevance. Filter the elements deemed irrelevant confirm whether removing each item would alter the prompt's meaning. Remove irrelevant components. The resulting cleaned prompt is effectively a more robust version of the initial one, which might exclude certain oddities added by attackers and avoid their effect. 73 | 74 | `🔁 Active` `📥 Input-focused` `🌐 Generic` `🤖 Automated` `🕰️ High Time Overhead` `💰 High Cost` 75 | 76 | 77 | ## 🚧 Type Enforcement 78 | In some cases, we can validate a strict output format for the LLM prompt. Prompt injection attacks often aim to yield remote code execution. Therefore, ensuring a specific output format eliminates many loopholes for potential attackers and limits the attack vectors. This technique is particularly useful when translating LLM outputs based on untrusted or tainted inputs into sensitive actions like API calls and commands. 79 | 80 | `🚦 Passive` `🛡️ Preventive` `📤 Output-focused` `🌐 Generic` `👥 Manual` `⚡ Low Time Overhead` `💲 Low Cost` 81 | 82 | 83 | ## 🎯 Fine-tuned or RAG-assisted Injection Characterization 84 | An LLM prompt containing information about common prompt injection methods can aid in identifying signs of these techniques. Using Retrieval Augmented Generation (RAG) or models fine-tuned for particular techniques can enhance this process. 85 | 86 | `🔁 Active` `🧠 Predictive` `📥 Input-focused` `🔬 Specific` `👥 Manual` `🕰️ High Time Overhead` `💰 High Cost` 87 | 88 | 89 | ## 🌈 Model Diversification 90 | Introduce diversity by incorporating different LLM models. If two models provide diametrically opposite outputs in sentiment analysis, we can consider rejecting the prompt or retrying until the outputs are similar. This technique may detect instances where an injection attack subverts one model, but fails to subvert another, resulting in diametrically opposite outputs. 91 | 92 | `🚦 Passive` `⚠️ Reactive` `📤 Output-focused` `🌐 Generic` `🤖 Automated` `⚡ Low Time Overhead` `💰 High Cost` 93 | 94 | ## 🐤 Canary Tokens 95 | Embed unique identifiers (canary tokens) into the prompt which should not appear in the output under normal conditions. If these tokens are detected in the output, it suggests an attack attempting to leak hidden aspects of the prompt. This technique helps to identify and mitigate such malicious activities. 96 | 97 | `🔁 Active` `🧠 Predictive` `📥 Input-focused` `🔬 Specific` `🤖 Automated` `⚡ Low Time Overhead` `💲 Low Cost` 98 | 99 | --- 100 | 101 | # 🏷️ Mitigation Categories 102 | It's useful to break down technique traits into categories to better understand how each technique is interacting with the threat as well as the time and cost trade-offs involved. 103 | 104 | ## 🔁 Active vs 🚦 Passive 105 | Active mitigation techniques involve proactive steps to neutralize a potential attack whereas passive techniques block attacks by simply not allowing them to proceed. 106 | 107 | ## 🕰️ High Time Overhead vs ⚡ Low Time Overhead 108 | Mitigations involving LLM inputs, especially in multiple synchronous steps can require the process to take longer compared to non-LLM mitigations or single / asynchronously executed LLM prompts. 109 | 110 | ## 💰 High Cost vs 💲 Low Cost 111 | Mitigation techniques which involve numerous additional LLM prompt steps are more resource-intensive requiring greater cost overhead relative to low cost techniques involving a single added LLM prompt or none at all. 112 | 113 | ## 🛡️ Preventive vs ⚠️ Reactive 114 | Preventive techniques try to stop an attack before it occurs while reactive techniques respond to an attack after it has happened, mitigating the impacts. 115 | 116 | ## 🧠 Predictive vs 🪂 Responsive 117 | Predictive techniques rely on modeling and forecasting to spot and stop potential attacks whereas responsive methods respond to a detected threat. 118 | 119 | ## 📥 Input-focused vs 📤 Output-focused 120 | Input-focused techniques seek to sanitize or control the input to prevent malicious use while output-focused techniques focus on turning manipulated outputs into less valuable ones for attackers. 121 | 122 | ## 🌐 Generic vs 🔬 Specific 123 | Generic techniques can be applied broadly to tackle different types of attacks while specific techniques specialize in thwarting a particular type of attack. 124 | 125 | ## 🤖 Automated vs 👥 Manual 126 | Automated mitigation will continue working with no human intervention whereas manual mitigation techniques require human intervention on a continuous basis, for example to introduce new threat signatures. 127 | 128 | --- 129 | 130 | # 📜 Relevant Literature 131 | 132 | - [Universal and Transferable Adversarial Attacks on Aligned Language Models](https://llm-attacks.org/) - Zou et al. 133 | - [A LLM Assisted Exploitation of AI-Guardian](https://arxiv.org/abs/2307.15008) - Nicholas Carlini, Google DeepMind 134 | - [A Complete List of All (arXiv) Adversarial Example Papers](https://nicholas.carlini.com/writing/2019/all-adversarial-example-papers.html) - Carlini 135 | 136 | --- 137 | 138 | # 🛠️ Free & Open Source Mitigation Suites: 139 | 140 | ### [Rebuff.ai](https://github.com/protectai/rebuff) 141 | 142 | "Rebuff is designed to protect AI applications from prompt injection (PI) attacks through a multi-layered defense." 143 | 144 | --- 145 | 146 | This is an early draft and feature-incomplete document. Contributions are welcome. I can be contacted for discussion [here](https://www.linkedin.com/in/jonathanktodd/). *Views and opinions expressed here are my own and do not represent those of my employer.* 147 | --------------------------------------------------------------------------------