Defender Impact
Security teams have long lacked a structured, vendor-neutral framework for classifying how AI systems cause harm to end users. F-Secure’s AI Harms Taxonomy directly closes that gap by giving defenders a common language and an intervention map they can apply before an incident occurs rather than after.
Capability Overview
F-Secure has released an AI Harms Taxonomy that identifies 26 discrete pathways through which AI systems can cause harm to consumers. The taxonomy is notable not simply for the count of harm categories, but for its architectural framing: it traces how harm moves through an AI system, from initial inputs — such as a user interacting with a chatbot that returns misleading answers — through intermediate processing stages, and out to the most complex failure mode in modern deployments: compromised autonomous agents.
This propagation-centric view is a meaningful shift from earlier harm lists, which typically treated AI risks as point failures rather than as cascading chains. By mapping harm as a flow, the taxonomy surfaces the intervention points where defenders can apply controls — input validation, output filtering, agent permission scoping, and runtime monitoring among them.
The scope spans consumer-facing AI surfaces across the full deployment stack. Chatbot output integrity, autonomous agent behaviour, and intermediate pipeline stages are all covered, making this relevant not only to AI product security teams but to any organisation operating AI-augmented customer-facing services.
Defensive Advances
Structured intervention mapping. For the first time defenders have a published, externally validated framework that tells them where in an AI pipeline a control can interrupt harm propagation. This moves AI security from reactive incident classification to proactive pipeline hardening.
Common vocabulary for AI incident classification. Cross-functional teams — legal, compliance, security, product — frequently stall on AI risk discussions because terminology is inconsistent. This taxonomy provides a shared reference that can accelerate both risk assessment and post-incident review.
Agentic AI coverage. The explicit inclusion of autonomous agent compromise scenarios is particularly timely. As agentic deployments expand, defenders have had limited structured guidance on the harm surfaces they introduce. This taxonomy begins to fill that gap.
AI risk register alignment. Organisations building internal AI governance programmes can use the taxonomy as a baseline classification scheme, reducing the effort required to build harm registers from scratch and improving comparability across business units.
Residual Gaps
The taxonomy, as reported, is a classification framework — not a technical control specification. Organisations will need to invest in translating each of the 26 harm categories into concrete detection logic, policy guardrails, or tooling integrations. That translation work is non-trivial and will vary significantly by deployment context.
Maturity in applying the framework will depend on how well security teams understand the specific AI components in their own stack. Teams without visibility into model selection, prompt design, and agent tooling will struggle to map harm categories to actionable controls.
The taxonomy’s consumer focus may also limit direct applicability in enterprise or critical infrastructure AI deployments, where harm propagation paths and stakeholder impact models differ materially. Defenders in those sectors should treat this as a starting point for adaptation rather than a ready-made fit.
Finally, without accompanying assessment tooling or vendor adoption, the taxonomy risks becoming a compliance artefact rather than an operational instrument. Uptake will depend on whether ecosystem partners — AI providers, platform vendors, auditors — align their own frameworks to it.
Framework Mapping
The taxonomy maps meaningfully to MITRE ATLAS techniques covering LLM output manipulation (AML.T0057, AML.T0060), agent context interference (AML.T0080, AML.T0099), and agentic exfiltration paths (AML.T0086). On the OWASP LLM Top 10 side, the harm categories span Prompt Injection (LLM01), Insecure Output Handling (LLM02), Excessive Agency (LLM08), and Overreliance (LLM09) — confirming broad alignment with existing defensive frameworks.
Deployment Considerations
Organisations should begin by running a lightweight mapping exercise: take each AI system in scope and walk the 26 harm categories to identify which apply and whether a control exists at the relevant intervention point. Prioritise agentic deployments first, as these carry the highest harm-propagation risk and the thinnest existing control coverage.
This framework pairs well with AI-specific threat modelling processes such as STRIDE-AI or MITRE ATLAS-based red-teaming. It should not replace those processes but can structure their scope.
Defender Checklist
- Inventory all consumer-facing AI systems and annotate which of the 26 harm categories apply to each
- Identify intervention points in each pipeline where controls can interrupt harm propagation
- Update AI incident response playbooks to reference taxonomy categories for consistent classification
- Use the taxonomy as the basis for the next AI-focused tabletop exercise
- Assess whether existing AI governance documentation can be restructured around the harm categories for improved auditability
- Track ecosystem adoption — if key AI vendors or auditors adopt the taxonomy, align internal frameworks accordingly