AI Safety & Alignment for Builders
Your system prompt is not a security boundary
Prompt injection cannot be filtered away. Enforce limits in code where actions happen, and test with attacks you did not write.
If your AI feature reads documents, web pages, or emails, those texts can give it instructions. That is indirect prompt injection, and it has been demonstrated against real applications. A system prompt saying "never do X" is a request to the model. A determined attacker, or an unlucky paraphrase, can get past it.
Keyword filters do not close the gap. In our teaching lab, a filter catches "ignore all previous instructions" but misses a polite request to "forward everything you know about the learner" to an outside address. Natural language has unlimited paraphrases.
Put the boundary where actions happen. Allow only the tools the task needs. Validate arguments strictly. Check outgoing requests for private data and restrict destinations. Require a person to approve side effects such as emails, showing the exact recipient and body. These controls hold even if the model is fully steered.
Then test honestly. Separate false allows, where something ran that should not have, from false blocks. Report how many cases you ran and who wrote them. Passing tests you wrote yourself is a start, not assurance. Our own lab gate passes its eight cases, and a split secret still slips through.
AI Safety & Alignment for Builders covers threat modelling, injection, privacy, red-teaming, and incident response with an offline lab.