Securing AI systems

Security teams have spent two years watching AI arrive faster than it can be assessed. Developers embed models into products, business units adopt copilots, and somewhere in the estate a downloaded model file is running with nobody able to say where it came from. AI systems are software, and most software security disciplines still apply — but they also fail in ways software never did, and the new failure modes are the ones nobody's runbook covers. This playbook maps the surface and the disciplines that hold it. 1. Find the AI you already have Every AI security program starts with an inventory it does not expect. Models embedded in vendor products, copilots adopted team by team, notebooks calling external APIs with company data, fine-tuned weights sitting in object storage. Discover before defending: what models run where, what data each can reach, what each can do, and who owns it. The unowned entries are the finding — an AI system without an owner is an incident with a start date nobody wrote down. 2. The model supply chain A downloaded model is third-party code that arrives as opaque weights — it cannot be read, only tested. Treat the model supply chain with the discipline the software supply chain took a decade to learn: known provenance for every model and dataset, integrity checks before anything runs, dependency scanning for the frameworks around it, and a registry of what is approved. A model pulled from a public hub into production without validation is an unaudited executable with a marketing page. 3. Injection and leakage Generative systems have a property classical software never had: their instructions and their input share a channel. Anything the model reads — a document, a web page, a customer message — can attempt to become an instruction, and anything in the model's context can attempt to leave. The defences are layered, not singular: separate and mark untrusted input, constrain what the system can disclose and do regardless of instruction, filter both directions of the channel, and test the whole assembly adversarially — because the attacker will, and this class of attack is written in plain language, not shellcode. 4. Contain the agents An agent extends the injection problem with hands. A poisoned input to an agent is not just a wrong answer risk; it is an action risk — the email sent, the record changed, the tool invoked. Containment is architectural: least-privilege credentials scoped per task, approval gates on irreversible actions, sandboxed execution, and kill switches that operate at the agent's speed. The identity and API disciplines already in this series are the substrate; an agent program that skipped them has no floor to stand on. 5. Watch it run, plan for the day AI systems drift, degrade, and get probed — often quietly. Monitor behaviour against the evaluation baseline, watch for the patterns of probing and extraction, and log at the level the incident will need: what went in, what came out, under which version, on whose behalf. Then extend the incident-response plan to AI specifically: how a compromised or manipulated model is contained, rolled back, and investigated. The teams that rehearse a poisoned-model scenario once will handle the real one; the teams meeting the concept mid-incident will improvise. 6. The first 90 days Run AI discovery and publish the honest inventory, owners attached. Put provenance and integrity checks in front of the next model deployment. Adversarially test the most exposed generative system — the customer-facing one — and fix what falls out. Scope the first agent's credentials as if it were a new administrator, because functionally it is. And add the AI scenario to the next incident rehearsal, before the calendar decides for you. AI security is not a new discipline so much as every existing discipline, applied to software that reads its instructions off the wire. The organisations treating it that way are unremarkable in the best possible sense.