AI security is not a new discipline so much as a new attack surface that cuts across several old ones. Prompt injection is an application security problem with a novel input. Model weight theft is data security with an unusually valuable file. Agent credential abuse is identity and access management for a new kind of principal. Poisoning is supply chain security for opaque artefacts. Evaluation escapes are containment engineering. What is new is that nobody owns the whole picture, and the 2025 and 2026 incident record is a catalogue of what falls through the gaps. A programme is the mechanism for closing them.
Ownership and scope
Give AI security an accountable owner in the security organisation with a mandate that spans the AI lifecycle: data, training, models, applications, agents, and the platforms and vendors that supply them. Define scope broadly enough to include shadow AI, the tools employees connect on their own, because the Samsung leak and every MCP inventory since show that the connections nobody approved are the ones that matter. Establish a working relationship with model risk management, privacy, legal and the AI product teams, because the controls will live in their systems. Report to the board on the same cadence as cyber risk, with the same metrics discipline.
Inventory
The first deliverable is an inventory that answers, for every AI system: what model, from whom, under what terms; what data it can read; what sources can write into its context; what tools and credentials it holds; what sinks its output reaches; who owns it; and which regulations apply. Generate it from build metadata and gateway telemetry rather than surveys where possible, and express it as an AI bill of materials so it stays current. The lethal trifecta test applied to the inventory produces the first risk ranking without any further analysis. The inventory also satisfies half of what the EU AI Act, the CPPA's audit regime, NIST's frameworks and the CSA AI Controls Matrix ask for.
Threat model
Structure the threat model with the taxonomies that regulators and peers use. NIST AI 100-2 for attack classes across predictive and generative systems; MITRE ATLAS for tactics, techniques and the detection vocabulary; the OWASP LLM, Agentic and MCP Top 10 lists for application and agent risks; CSA MAESTRO for the layered decomposition of agent systems; RAND's attack vectors for weight security. For each system in the inventory, identify which classes apply and which attackers matter: an internal productivity assistant faces opportunistic injection and data leakage; a customer agent with payment tools faces determined fraud; a fine-tuned model embodying proprietary process faces extraction and insider theft; an evaluation sandbox faces the model itself. Write the threat model down; it is the artefact that justifies every control that follows and the first thing an auditor will ask for.
Control library
Build one control library and map it to every framework you must answer to, rather than a compliance project per framework. The CSA AI Controls Matrix and NIST's overlays are designed as backbones; ETSI TS 104 223 supplies lifecycle provisions; ISO/IEC 42001 supplies the management system wrapper. The controls themselves fall into recognisable families.
- Data: provenance, filtering, canaries, fine-tuning data review, differential privacy where regulated data is involved.
- Artefacts: code-free formats, scanning, signing verified at load, AIBOM.
- Models: weight protection proportionate to the RAND level, extraction monitoring, before-and-after safety validation for fine-tunes, vendor due diligence on frameworks and Model Reports.
- Applications: dual-model separation of planning from untrusted content, output validation at sinks, retrieval authorisation, hidden context hygiene, classifiers as probability-lowering layers, rate limiting.
- Agents: no standing credentials, delegated task-scoped tokens, approval gates bound to parameters, OS-level sandboxing, egress allowlists, memory validation, MCP admission process.
- Monitoring: real-time monitors with authority to halt, attributed logs with regulatory retention, ATLAS-mapped detections.
- Testing: breadth scans in CI, adaptive red teaming on a cadence, external evaluation for high-stakes systems, utility measured alongside security.
- Incident response: AI-specific playbook, multi-regime reporting decision tree, kill switches, tabletops.
Evidence
A programme that cannot show its work does not exist for a regulator, a customer or a board. Each control should link to evidence: red team reports with attack success rates and transcripts, gateway configuration, signing logs, sandbox policies, monitor coverage, incident records. Package it once, in the structure of the CSA matrix or NIST, and reuse it for questionnaires, the CPPA's cybersecurity audit, the EU AI Act's technical documentation and the frontier frameworks' expectations if you are a developer. The SaaS case study in this knowledge base cut questionnaire effort by 71 percent by doing exactly this.
Metrics for the board
Report a small set of measures that move: percentage of AI systems in inventory with an owner and a threat model; percentage of agents with no standing credentials; percentage of systems covered by real-time monitoring; attack success rates from red teaming over time, by class; mean time to halt an agent; number of AI supply chain artefacts unsigned; incidents by ATLAS technique and by regulatory regime; and time to report against each clock. These are the numbers that show whether the programme is reducing exposure, and they are the ones a director should ask about.
Sequencing
Quarter one: owner, inventory, trifecta ranking, kill switches, incident playbook. Quarter two: threat model, control library mapping, agent credential and sandbox work on the highest-ranked systems, MCP admission process. Quarter three: signing and AIBOM, red team cadence, monitoring with halt authority, evidence pack. Quarter four: external evaluation for the highest-stakes systems, regulatory alignment (Article 15 catalogue, CRA vulnerability handling, CPPA audit readiness), metrics to the board. Adjust to your exposure, but do not let the sequencing invert: inventory and containment before elegance.
The standard to aim at
The frontier developers' 2026 post-mortems set a bar most organisations will never need to reach, but their shape is the right one: name the threat honestly, show the controls, disclose what failed and what changed, and admit what remains unknown. An AI security programme that can do that for its own systems is credible with regulators, customers and its own board, and it will be far better placed the day one of its agents does something nobody told it to.
