Securing the models, agents and pipelines you deploy. Distinct from AI governance, which covers the paperwork proving a system is lawful. This domain covers the system being attacked or misused.
What we track
Technical authority guidance
UK, US and international. NCSC, CISA and partner guidance on secure AI development and deployment.
AI Act security requirements
EU. Accuracy, robustness and cybersecurity obligations for high-risk systems, and what evidences them.
Singapore CSA code of practice
Singapore. Updates addressing AI-enabled threats and advanced persistent threat activity.
Agent and tool-use risk
All jurisdictions. Where regulators and standards bodies are addressing systems that take actions instead of producing text.
Model supply chain
All jurisdictions. Model provenance, weights, and the export conditions now attached to them.
Incident precedent
All jurisdictions. What has gone wrong in deployed systems, and what the response required.
Who is in scope
Anyone deploying a model, which now includes organisations that never made an AI decision. Features arrive inside products already in use, and a security team can inherit a deployed model through a vendor release note.
Formal obligations attach through the AI Act for high-risk systems, and through the general security duties in NIS2, DORA and Article 32 for everything else. There is no separate AI security statute in most jurisdictions, so the duty usually arrives as an existing obligation applied to a new component.
Where the deadlines fall
Few fixed dates, and that is the difficulty. Guidance from technical authorities lands without a compliance clock, and it becomes the standard a regulator or an insurer measures you against later. The binding dates come from the AI Act phases and from sector codes of practice.
Where organisations get caught
Permissions. An agent with credentials is an identity, and most organisations gave it those credentials through a project, with no access review anywhere near it. The blast radius of a prompt injection is whatever that identity can reach, which is a question about your access model and not about the model itself.
You are securing something you did not build and cannot inspect. Assurance has to come from the boundary you control, which means input handling, output handling and what the system is allowed to do. Teams that go looking for assurance inside the model spend a long time and arrive nowhere useful.
Evaluation is not testing. A benchmark score describes average behaviour on a fixed set of inputs. It says nothing about an adversary choosing inputs specifically, which is the threat model that matters, and it is the gap most vendor assurance material quietly leaves open.
Questions worth asking now
- Which AI systems can take an action, as opposed to producing text a person then acts on?
- What identity does each of them use, and what can that identity reach?
- Who reviewed those permissions, and when are they reviewed again?
- What happens to untrusted content before it reaches a model, and to model output before it reaches a system?
- If a model provider disclosed a serious flaw tomorrow, which of our systems would be affected?
- Have we tested any of this adversarially, or only measured accuracy?
Related domains
AI governance covers the classification and documentation duties. Third-party and supply chain risk covers model and provider assurance. Export controls covers the licence conditions now attached to model weights.