AML.T0048 External Harms: Plan for the Damage Abused AI Causes

Most AI attacks end with harm outside the AI system: money lost, trust damaged, users exposed or a model's value taken by someone else. MITRE ATLAS tracks that end state as AML.T0048 External Harms, in the Impact tactic (AML.TA0011). ATLAS describes adversaries abusing access to a victim system and using its resources or capabilities to cause harms that reach the organisation, its users or the general public, and splits the technique into five sub-techniques: Financial Harm, Reputational Harm, Societal Harm, User Harm and AI Intellectual Property Theft. This guide is for AI risk owners, security architects and incident responders who need to scope impact, design controls that cap it and measure exposure. For how AI output can mislead people, see the OWASP LLM Top 10 LLM09 Misinformation Guide; for the framework, the MITRE ATLAS Guide.

Key takeaways

• External Harms is an outcome, not an entry point. It is reached through other techniques such as stolen credentials, prompt injection or model extraction, so most prevention sits earlier in the chain.
• Five sub-techniques, five owners. Finance, communications, trust and safety, privacy and the AI product team each own one harm type, and each needs a plan before an incident.
• ATLAS maps mitigations only to IP theft. AML.M0005 Control Access to AI Models and Data at Rest, AML.M0012 Encrypt Sensitive Information and AML.M0017 AI Model Distribution Methods are mapped to AML.T0048.004; the other harm types depend on controls for the techniques that lead to them.
• Cap the blast radius in advance. Spend limits on AI services, human approval for payments, output safeguards and least privilege for agents decide how large the harm can get.
• Identity is the usual path to financial harm. Many ATLAS financial harm cases start with stolen keys or accounts, so non-human credential hygiene is an impact control.

What ATLAS includes under External Harms

ATLAS lists the technique for predictive, generative and agentic AI and for enterprise platforms. The sub-techniques are not exclusive: one incident often causes several harm types at once.

How the harms arise

Financial harm

ATLAS records several paths. In the LLMjacking case, Sysdig reported in May 2024 that attackers used stolen cloud credentials to access hosted LLMs and resell access, and estimated the worst-case cost of abusing one Claude 2.x model at up to $46,000 a day. See the LLMjacking breach analysis. In the ID.me case (AML.CS0017), an individual passed automated identity verification with fake driving licences and matching selfies, then filed false unemployment claims; the US Attorney's Office for the Eastern District of California charged him in January 2022 with at least 78 fraudulent claims seeking more than $2.5 million, while the ATLAS case study cites at least 180 claims and at least $3.4 million received. ATLAS also links financial harm to an agent-assisted wire fraud scenario against Microsoft 365 Copilot (AML.CS0026) and to compromised Ray clusters used for crypto mining (AML.CS0023).

Reputational harm

ATLAS defines this as degraded public perception and trust, with scandals and false impersonations as examples. In PoisonGPT, Mithril Security researchers poisoned an open-source model to return a false fact and uploaded it back to Hugging Face to show the weakness of the LLM supply chain; ATLAS notes users may lose trust in the original model's creators. The neighbouring AML.T0060 Publish Hallucinated Entities guide covers another trust-damaging route: AML.T0060 Publish Hallucinated Entities.

Societal harm

Harm that reaches the general public or vulnerable groups. Microsoft's February 2025 account of Storm-2139 describes a network that used leaked customer credentials to access generative AI services, altered their capabilities, resold access and supplied instructions for producing harmful imagery, including non-consensual intimate images of celebrities. ATLAS also cites Anthropic's warning that models built by illicit distillation may lack the safeguards of the source model (AML.CS0056).

User harm

Harm felt by individual victims rather than the organisation. ATLAS case studies show user data leaving AI assistants through indirect prompt injection, poisoned assistant memory misleading a user (AML.CS0040), and data exposed to a malicious MCP server (AML.CS0054). Agentic systems widen this category because the assistant can act, not only answer.

AI intellectual property theft

ATLAS updated this sub-technique in its October 2026 release. Targets include model architectures and weights, training data and model behaviours. Two routes are described: exfiltrating artifacts through valid accounts, exposed storage, misconfigured permissions or exploited systems, or collecting AML.T0135 Outputs from AI Models to replicate behaviour through AML.T0005 Replicate AI Model Behavior, using distillation, fine-tuning or reinforcement learning. A stolen model can then be run outside the owner's access controls and monitoring. See the Model Extraction and Distillation Defence Guide.

Controls that cap each harm

Because ATLAS maps mitigations only to AML.T0048.004, the controls for the other rows below are NHI Mgmt Group recommendations that limit how large the harm can become once an earlier technique succeeds.

Where identity fits

Financial and societal harm cases in ATLAS repeatedly start with a credential: cloud access keys in LLMjacking, leaked customer credentials in Storm-2139, valid accounts in IP theft. API keys and service accounts for AI platforms should be inventoried, scoped to the models and regions in use, rotated, and monitored for use from new locations. The LLMjacking Guide covers key protection in depth, and the Deepfake-Resistant Identity Verification Guide covers the proofing side of cases like ID.me.

Implementation: an impact-first approach

1. Inventory AI systems by harm potential: for each, record what it can spend, what it can say publicly, which users' data it can reach, what it can do through tools, and what model assets it holds.
2. Assign an owner per harm type: finance for spend and payments, communications for reputation, trust and safety for abuse, privacy for user data, the AI product owner for IP.
3. Set hard limits first: spend caps and quotas on every AI service key, approval gates for payments, and least privilege for agent tools. These work even when detection fails.
4. Protect model assets: restrict and log registry access, encrypt artifacts, and decide which models may ship to edge devices.
5. Pilot the response: run a tabletop for one harm type, such as a stolen key generating a large bill, and test the alert, the revocation and the cost recovery steps.
6. Roll out and review: extend to all systems, then review limits after each incident or major model change. Roll back a limit only with a recorded business reason.

Detection and measurement

Metrics that show exposure is falling:

• Percentage of AI service keys with an enforced spend cap or quota.
• Mean time from anomalous AI spend to key revocation.
• Percentage of agent actions with financial effect that require human approval.
• Percentage of model artifacts encrypted and held in access-controlled registries.
• Number of AI incidents in the last year with a named harm owner and completed review.

Framework mapping

Common failure patterns

• No spend ceiling on AI keys: a stolen key runs until the invoice arrives, as the LLMjacking cases show.
• Agents allowed to move money alone: an assistant that can prepare and send payment changes turns a prompt injection into financial harm.
• Treating models from hubs as trusted by default: unverified uploads make reputational and user harm easy, as PoisonGPT demonstrated.
• Model artifacts in open storage: weights and training data in broadly readable buckets or registries make IP theft a copy operation.
• Impact owned by nobody: security finds the cause but no business owner has a plan for the bill, the press or the affected users.

Practitioner checklist

• List each AI system with its potential financial, reputational, societal, user and IP harm.
• Name an owner for each harm type and agree escalation routes.
• Enforce spend caps, quotas and region limits on every AI service credential.
• Require human approval for agent actions with financial or external effect.
• Verify model provenance and publisher identity before using third-party models.
• Encrypt model artifacts and restrict registry and training data access to named roles.
• Monitor AI spend, content safety violations and systematic querying.
• Run at least one AI harm tabletop per year and record the lessons.

Standards and references

• MITRE ATLAS: External Harms
• MITRE ATLAS: Impact tactic
• OWASP: LLM09:2025 Misinformation
• NIST: AI 100-2 E2025 Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
• US Attorney's Office EDCA: New Jersey man indicted in fraud scheme to steal California unemployment insurance benefits
• Sysdig: LLMjacking: Stolen Cloud Credentials Used in New AI Attack
• Microsoft: Disrupting a global cybercrime network abusing generative AI

Related NHI Mgmt Group resources: MITRE ATLAS Guide · OWASP LLM Top 10 LLM09 Misinformation Guide · AI Model Theft Response Playbook · LLMjacking Guide · MITRE ATLAS Mitigations Guide