Risk lists and attack knowledge
OWASP Top 10 for LLM Applications
2025 edition[1]
The ten most important security risks of applications built on large language models, published by the OWASP Gen AI Security Project. The 2025 entries are LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation and LLM10 Unbounded Consumption.[1] It is the common vocabulary for LLM application risk, and the first column of our finding record.
Mapped in A2, A3, S1, S3, AG3, AG11
OWASP Top 10 for Agentic Applications
2026 edition, published 9 December 2025[2]
The same idea for autonomous and agentic AI systems: agents that plan, call tools, keep memory and work with other agents. The ten entries run from ASI01 Agent Goal Hijack through Tool Misuse and Exploitation, Identity and Privilege Abuse, Agentic Supply Chain Vulnerabilities, Unexpected Code Execution, Memory and Context Poisoning, Insecure Inter-Agent Communication, Cascading Failures and Human-Agent Trust Exploitation, to ASI10 Rogue Agents.[3] Every one of our agent scopes maps to it.
Mapped in A2, S1, S2, AG1, AG2, AG3, AG4, AG5, AG6, AG7, AG8, AG9, AG10, AG12
OWASP MCP Top 10
Beta[4]
A list of the main risks of Model Context Protocol servers and clients, from MCP01 Token Mismanagement and Secret Exposure to MCP10 Context Injection and Over-Sharing. It is still in beta and pilot testing,[4] so we use it as a checklist alongside the MCP project’s own security best practices rather than as a fixed standard.
Mapped in S2, AG1
MITRE ATLAS
Monthly releases; data version 2026.05[5][6]
ATLAS (Adversarial Threat Landscape for AI Systems) is MITRE’s public knowledge base of adversary tactics, techniques and procedures against AI systems.[6] Each technique has an ID; for example AML.T0051 is LLM Prompt Injection and AML.T0051.001 its indirect form, where the malicious prompt arrives in data the model reads from another channel.[7][8] ATLAS now releases monthly, and its April 2026 updates added more than forty-five techniques and sub-techniques.[5] Because it moves fast, every report records the ATLAS data version it used.
Mapped in A2, S1, AG3, AG5, AG7
NIST AI 100-2 E2025, Adversarial Machine Learning
March 2025[9]
NIST’s taxonomy and terminology of attacks on machine learning and their mitigations, organised by attack type, life-cycle stage, and the attacker’s goals and capabilities.[9] We use it to make sure a threat model has not missed a class of attack.
Mapped in A2
Testing and incident response
OWASP GenAI Red Teaming Manual
Version 1.0, 20 October 2026[10]
A structured, eight-phase approach to testing the security, safety and robustness of generative AI models, applications and agents.[10] Our red-teaming scope draws on it for how an engagement is planned and run.
Mapped in S1
OWASP GenAI Incident Response Guide
Version 1.0, 28 July 2025[11]
Guidelines and practices for responding to security incidents that involve generative AI applications, written for security practitioners without deep GenAI expertise.[11]
Mapped in G2, AG12
CoSAI AI Incident Response Framework
V1.0, released 18 November 2025[12]
From the Coalition for Secure AI, an OASIS Open Project: AI-specific guidance and playbooks for detecting, containing and recovering from threats such as data poisoning, model theft, prompt injection and inference attacks.[12]
Mapped in G2, AG12
Risk management and secure development
NIST AI Risk Management Framework
AI RMF 1.0, released 26 January 2023; being revised[13]
The US National Institute of Standards and Technology’s voluntary framework for managing the risks of AI systems. NIST states that version 1.0 is being revised as part of the White House AI Action Plan,[13] so we cite the version a report uses.
Mapped in AG11
NIST AI 600-1, Generative AI Profile
26 July 2024[14]
A companion to the AI RMF for generative AI.[14] It defines twelve risks that generative AI creates or makes worse, among them Confabulation, Data Privacy, Information Integrity, Information Security, and Value Chain and Component Integration.[15] Each finding records the risk it increases.
Mapped in A3, S3
NIST SP 800-218A
Final, July 2024[16]
Secure software development practices for generative AI and dual-use foundation models: a profile that adds AI-specific practices to NIST’s Secure Software Development Framework, for those who create models, build AI systems or buy them.[16]
Mapped in S4
NIST IR 8596, Cyber AI Profile
Initial preliminary draft, 16 December 2025; comments closed 30 January 2026[17]
A draft profile of the NIST Cybersecurity Framework 2.0 for artificial intelligence, covering both the cybersecurity risks of AI systems and the use of AI for defence.[17] It is still a draft; we watch it and will map to it when it is final.
NCSC Guidelines for secure AI system development
Version 1.0, 27 November 2023[18]
Guidance from the UK National Cyber Security Centre organised by the four stages of the AI system life cycle: secure design, secure development, secure deployment, and secure operation and maintenance.[18] It frames our architecture review.
Mapped in A1
Google Secure AI Framework (SAIF)
SAIF introduced 8 June 2023; SAIF 2.0, 6 October 2025[19][20]
Google’s framework for securing AI systems, first published with six core elements.[19] SAIF 2.0 extends it to autonomous agents with an agent risk map, and Google donated SAIF’s risk map data to the Coalition for Secure AI.[20] Naming it here implies no relationship with Google.
Mapped in A1
CSA AI Controls Matrix
v1 released 9 July 2025; v1.1 is current[21]
The Cloud Security Alliance’s catalogue of 243 control objectives in 18 security domains for AI, with mappings to ISO/IEC 42001, ISO/IEC 27001, the NIST AI RMF, BSI AIC4 and the EU AI Act.[21] Useful when a design review has to show which controls it checked.
Mapped in A1
International standards
ISO/IEC 42001:2023
Published 17 December 2023[22]
The international standard for an AI management system: requirements for establishing, implementing, maintaining and continually improving how an organisation governs AI.[22] Its Annex A sets out nine control objectives, from A.2 Policies related to AI to A.10 Third-party and customer relationships, with 38 controls.[23] Each finding records the control objective it touches.
Mapped in G1
ISO/IEC 27090:2026
2026; BSI release of 27 October 2026[24]
New international guidance on security threats to AI systems. It explains how attacks such as data poisoning, prompt injection, model theft and leakage of training data or model inputs can affect AI data, models, outputs and services across the life cycle, maps threats to the assets they affect and the stages where they arise, and is designed to feed AI-specific risks into an existing ISO/IEC 27001 security programme or ISO/IEC 42001 governance rather than create a separate management system.[24]
Mapped in A1
ISO/IEC 29147:2018, Vulnerability disclosure
Edition 2, October 2018[25]
Guidance for vendors on receiving and sharing information about vulnerabilities in their products and services, so that users can manage the risk.[25] Our own disclosure policy follows it.
RFC 9116, security.txt
April 2022[26]
A small text file at a known address that tells researchers how to report a vulnerability. It must carry a Contact and an Expires field, and is placed under the /.well-known/ path.[26] Ours is at /.well-known/security.txt.
Agents and protocols
Model Context Protocol and its Security Best Practices
Specification version 2026-07-28[27]
MCP is an open protocol that connects LLM applications to external data sources and tools, using JSON-RPC between hosts, clients and servers.[27] The project now sits with the Agentic AI Foundation.[28] Its security best practices describe specific attacks and their mitigations: confused deputy problems in OAuth proxies, token passthrough, server-side request forgery during discovery, state handle hijacking, local server compromise, unsafe authorization URLs, mix-up attacks and over-broad scopes.[29]
Mapped in S2, AG1, AG8
MCP Authorization
Specification version 2026-07-28[30]
How MCP servers over HTTP authorise clients. It builds on OAuth 2.1, requires servers to publish OAuth 2.0 Protected Resource Metadata (RFC 9728, April 2025),[31] requires clients to name the server a token is for, and forbids servers from accepting or passing on tokens issued for anything else.[30]
Mapped in AG1, AG2
CoSAI Model Context Protocol security taxonomy
27 January 2026[32]
The Coalition for Secure AI’s taxonomy of MCP security: nearly forty threats and their mitigations in twelve categories.[32] We use it to check that an MCP audit is complete.
Mapped in S2, AG1, AG10
Agent2Agent (A2A) protocol
v1.0.1, May 2026[33]
An open protocol, under Apache 2.0 and governed by the Linux Foundation, that lets agents built on different frameworks and servers communicate and collaborate without exposing their internals.[34]
Mapped in AG6
Agent session smuggling
Research published 31 October 2025[35]
An attack on multi-agent systems in which a malicious remote agent uses an open A2A session to slip covert instructions to a client agent, hidden among normal requests and responses. The recommended defences are human approval through a channel the model cannot influence, context grounding, verified agent identities and visible agent activity.[35]
Mapped in AG6
CoSAI Agentic Identity and Access Management
Version 1.0, 20 March 2026[36]
Proposes managing AI agents as distinct, short-lived, auditable identities, with access controls that follow delegation, adapt to context and build on existing identity infrastructure.[36]
Mapped in AG2
NIST NCCoE concept paper on agent identity and authorization
Initial public draft, 5 February 2026[37]
A concept paper from NIST’s National Cybersecurity Center of Excellence proposing a project to show how existing identity standards and practices can secure AI agents, software that acts autonomously.[37]
Mapped in AG2
Agents Rule of Two
31 October 2025[38]
A design rule for agent security: within one session an agent should satisfy no more than two of three properties: it processes untrustworthy inputs, it can access sensitive systems or private data, and it can change state or communicate externally. A task that needs all three needs a new session or human supervision.[38]
Mapped in AG4
CaMeL: Defeating Prompt Injections by Design
arXiv 2503.18813, first version 24 March 2025[39]
A defence that wraps the model in a protective layer: it extracts the control and data flow from the trusted user request so that untrusted retrieved data cannot change the program’s flow, and uses capabilities to stop private data leaving through tool calls.[39]
Mapped in AG4
Design Patterns for Securing LLM Agents against Prompt Injections
arXiv 2506.08837, June 2025[40]
A paper proposing a set of principled design patterns for building agents with provable resistance to prompt injection.[40]
Mapped in AG4
MemGhost: persistent memory poisoning
Research note, 23 July 2026[41]
Showed that one crafted email to an inbox an agent monitors can make the agent write attacker-chosen falsehoods into its persistent memory. The note recommends limiting memory writes, separating untrusted readers from memory writers, tagging and confirming external entries, and logging every memory change.[41]
Mapped in AG5
OpenTelemetry semantic conventions for generative AI
In development; own repository since June 2026[42][43]
Shared names for the spans, metrics and events that GenAI clients, agents and MCP produce, so traces from different tools can be read together.[42] None of the conventions is marked stable yet,[43] so a monitoring design records the version it follows.
Mapped in AG8
Managed agent runtime documentation
As published by each provider; checked 4 November 2026
For managed runtimes, the provider’s own documentation is the reference for what each control does: for example policy enforced at a gateway in Amazon Bedrock AgentCore,[44] guardrails at the agent gateway on Google’s Gemini Enterprise Agent Platform,[45] and per-agent identity and network isolation in Microsoft Foundry Agent Service.[46] The full list is on the platforms page.
Mapped in AG9
EU law
EU AI Act
Regulation (EU) 2024/1689 of 13 June 2024, as amended by Regulation (EU) 2026/1744 of 8 July 2026[50][51]
The EU’s rules for AI systems, by risk class. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026.[52][53] As amended, the key dates are:
- Article 50 transparency obligations: from 2 August 2026; for systems already on the market, certain marking duties have a grace period to 2 December 2026.[52]
- New prohibited practices: from 2 December 2026.[52]
- High-risk systems listed in Annex III: from 2 December 2027.[53]
- High-risk systems in products covered by Annex I: from 2 August 2028.[53]
- Obligations for general-purpose AI models: not delayed.[53]
Two articles come up most in security work: Article 15 requires high-risk systems to be accurate, robust and secure, including technical measures against attacks on training data, pre-trained components and model inputs,[54] and Article 50 requires that people be told when they are dealing with an AI system.[55] Our readiness work does not guarantee compliance; your counsel decides how the Act applies to you.
Mapped in G1
GDPR
Regulation (EU) 2016/679 of 27 April 2016[56]
The EU’s data protection law. In AI work the articles we use most are Article 25, data protection by design and by default,[57] and Article 35, the data protection impact assessment required before processing likely to result in a high risk to people.[58]
Mapped in G1, AG11
EDPB Opinion 28/2024
December 2024[59]
The European Data Protection Board’s opinion on data protection in the context of AI models.[59] It addresses when a model trained on personal data can be considered anonymous, whether legitimate interest can be a legal basis for developing and deploying models, and what follows if a model was developed with unlawfully processed data.[60]
Mapped in G1
Cyber Resilience Act reporting
Reporting obligations from 11 September 2026; most obligations from 11 December 2027[61]
Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours, a notification within 72 hours, and a final report later, through ENISA’s single reporting platform.[61]
Mapped in G2
Post-quantum cryptography
FIPS 203, 204 and 205
Published 13 August 2024[62][63][64]
NIST’s first post-quantum standards: FIPS 203 specifies ML-KEM for key establishment, FIPS 204 specifies ML-DSA for digital signatures, and FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme.[62][63][64]
Mapped in G3
NIST IR 8547, Transition to Post-Quantum Cryptography Standards
Final, 27 October 2026[65]
NIST’s plan for moving from quantum-vulnerable algorithms to post-quantum signatures and key establishment.[65] Classical public-key algorithms such as RSA and elliptic-curve schemes are deprecated after 2030 and disallowed after 2035.[66]
Mapped in G3
EU and UK migration roadmaps
EU, 23 June 2025; UK NCSC, 20 March 2025[67][68]
The EU roadmap asks Member States to start the transition by the end of 2026 and to move critical infrastructure by the end of 2030 at the latest.[67] The UK’s NCSC sets three milestones: migration objectives and discovery by 2028, the highest-priority migrations by 2031, and migration of all systems, services and products by 2035.[68]
Mapped in G3