First, thank you for reading this far. Writing for the Ironman contest is genuinely hard work, and I suspect reading it has not been effortless either, so thank you for coming.
Looking back over the thirty posts#
On day one I said the series was called “AI Dark Arts” because so many people call the prompt you send an AI an incantation, and some people deliberately write a bad one to take control of it. A bad incantation can be typed straight in, or hidden in a document, an image, a web page, or the description field of a tool.
The kinds of dark art ran from prompt injection, jailbreaking, indirect injection and multimodal attacks, through unhandled output and excessive agency, to MCP connecting tools and connecting their risks along with them, and all of those sit at the application layer. Further down, what the attacker touches is no longer the text going in: the system layer is the old familiar security problems of keys and hosts, the supply chain is the malicious model file you downloaded, the data layer is poisoning and backdoors, and the inference layer is the handful of techniques that pull secrets out using nothing but queries.
Alongside the attacks, the later posts brought in some defensive thinking. An AI cannot tell which sentence is an instruction and which is data, and with content arriving, tools connecting and models downloading, there is very little chance of guaranteeing any one of them is clean. So the defense does not ride on validating content. It rides on three things you do control: give it only the permissions it actually uses, verify where it really came from, and keep a human confirmation in front of anything whose consequences cannot be undone.
For anyone just starting out#
If you are where I was a year ago, coming from traditional security and wanting to move into AI, here is what I have got:
From a security point of view, the principles matter more than the hard math and the algorithms. Read through this series and you will notice there is barely a formula in it, not because they do not matter, but because you have to understand how a model works before you can see how to attack it, how an attack chain forms, and where the defensive line belongs. When you reach the step that genuinely needs the math, you can go and learn it then.
The security background you already have does not go to waste. If you read the whole series you will have noticed how many old friends turned up. You are not starting from zero, you are using what you already know on a new stage:
- Model output that goes into a database or a browser unhandled still gives you SQL injection and XSS.
- An MCP server is the third-party package you
pip install. - When an agent goes wrong, it is usually still because the permissions were too wide.
If you are only starting to learn AI security now, you are not late at all. Much of the research, the frameworks and the incidents I cited only appeared in the last few years, the OWASP list keeps getting revised, the regulation has only just come into force, and nobody has solved prompt injection yet. Start learning and there is a real chance you find your first CVE, and a real chance you become the person leading AI adoption at your company.
Last of all#
Writing this series made me go back over what I had learned and put it in order, and plenty of things I only half understood at the time became clear because I had to look them up while writing. If these thirty days have given you a little more understanding of AI security and a little less fear of it, the series was worth it. Thank you again for coming along.