Most attackers do not build their AI attack tooling: they download it, buy it or borrow it, from research libraries and public exploits to uncensored models and ready-made agent tools. MITRE ATLAS records this as AML.T0016 Obtain Capabilities, a Resource Development (AML.TA0003) technique with five sub-techniques. It mirrors ATT&CK T1588 Obtain Capabilities, which the T1588 Obtain Capabilities guide covers in general; this page covers only the AI-specific angle. The counterpart for capabilities attackers build themselves is AML.T0017 Develop Capabilities. It is written for threat intelligence, AI platform, application security and detection teams.
Key takeaways
- Five kinds of obtained capability. ATLAS lists Adversarial AI Attack Implementations, Software Tools, Generative AI, Exploits and AI Agent Tools, and notes that capabilities used against AI systems are often not AI-based themselves.
- Public research code is dual use. ATLAS names research libraries such as CleverHans, the Adversarial Robustness Toolbox and Foolbox as capabilities an adversary can repurpose, so assume any published attack class will be tried against your models.
- Obtained agents change the tempo, not always the outcome. In the Hermes case ATLAS records an actor assembling an agent, models, an MCP server and public proofs of concept, yet the autonomous attempts failed against targets that required authentication.
- Your keys can become the attacker's capability. LLMjacking actors obtained a bulk key checker and a reverse proxy, turning stolen AI keys into a resale service, so key hygiene directly removes capability.
- Few preventive controls apply directly. ATLAS maps AML.M0001 Limit Model Artifact Release and AML.M0022 Generative AI Model Alignment; for most organisations the defence is hardening against the capabilities you can expect to meet.
What ATLAS says about the technique
ATLAS describes AML.T0016 as adversaries searching for and obtaining software capabilities for their operations, either AI-specific attack implementations or generic tools repurposed for malicious use, and possibly customised for a particular AI-enabled target. The parent technique has maturity "Realized" in the 2026.10 release and applies to Predictive AI, Generative AI, Agentic AI and Enterprise platforms. Exploits and AI Agent Tools were added as sub-techniques on 31 August 2026.
| Sub-technique | What is obtained | ATLAS maturity (2026.10) | ATT&CK mirror |
|---|---|---|---|
| AML.T0016.000 Adversarial AI Attack Implementations | Open source implementations of AI attacks published for research reproducibility, plus other tools adapted for AI attacks | Realized | None listed |
| AML.T0016.001 Software Tools | Legitimate software repurposed or customised; not necessarily AI-based | Realized | T1588.002 Tool |
| AML.T0016.002 Generative AI | LLMs and generative tools used to write malware, phishing, deepfakes or commands; open models served locally, hosted models, uncensored models and models advertised for malicious use | Realized | None listed |
| AML.T0016.003 Exploits | Exploits downloaded from public repositories, bought, stolen or shared, used as-is or adapted | Realized | T1588.005 Exploits |
| AML.T0016.004 AI Agent Tools | MCP servers, plugins, skills, connectors, function libraries, computer-use adapters and similar integrations that give an agent access to systems and credentials | Realized | None listed |
Cases ATLAS links to the technique
| Case study | Sub-technique | What was obtained | Defender lesson |
|---|---|---|---|
| AML.CS0002 VirusTotal Poisoning | .000 | The metame metamorphic code engine to produce mutated samples | Security ML that ingests public submissions will face off-the-shelf mutation tools |
| AML.CS0027 Organization Confusion on Hugging Face | .000 | EasyEdit, an open source knowledge editing tool for LLMs | Model editing research tools can alter published models; verify model publishers |
| AML.CS0004 Camera Hijack Attack on Facial Recognition | .000, .001 | Photo-to-video software, customised Android ROMs and a virtual camera app | Liveness checks need camera injection detection |
| AML.CS0033 and AML.CS0034 KYC deepfake cases | Parent, .001, .002 | Virtual camera apps, broadcast software, real-time face swap tools and a paid deepfake KYC tool | Identity proofing must assume commodity deepfake tooling |
| AML.CS0030 LLMjacking | .001 | A bulk AI service key checker and an open source reverse proxy for LLM access | Stolen keys are validated and monetised quickly |
| AML.CS0069 GTG-1002 Claude Code Espionage Campaign | .001 | Network scanners, database exploitation frameworks, password crackers and binary analysis utilities made available to a jailbroken agent | Commodity tools become far faster when an agent drives them |
| AML.CS0070 DeepSeek-powered Hermes agent | .001, .002, .003, .004 | An agent framework, several generative AI services, public proofs of concept for Langflow and n8n, and an open source MCP server for asset search and scan generation | Authentication and secure defaults defeated the autonomous attempts |
| AML.CS0055 AI ClickFix: Hijacking Computer-Use Agents Using ClickFix | .002 | Access to a commercial generative AI service (ChatGPT) | Hosted models are part of the attacker toolkit for testing agent attacks |
| AML.CS0072 AI Recommendation Poisoning | Parent | Public tooling (an npm package, a web link generator and website plugins) to create AI assistant links carrying memory instructions | Hunt for AI assistant URLs that carry prompt parameters |
Unit 42's report on the Hermes campaign is the clearest single example. Most autonomous attempts failed because the Langflow targets had neither auto-login enabled nor a public flow ID, and the n8n targets required authentication on their forms. The LLMjacking 2024 to 2026 page shows the key-checker and reverse-proxy pattern in the wild.
The generative AI sub-technique in practice
Two downstream uses have their own pages: AML.T0088 Generate Deepfakes and AML.T0102 Generate Malicious Commands.
ATLAS describes three sources of generative AI capability: open source models served locally with frameworks such as Ollama or vLLM, models hosted on cloud infrastructure or AI service providers, and hosted commercial models that may need jailbreaking and a breach of terms of service. Cisco Talos groups criminal use into the same pattern: uncensored models, models built and sold to criminals, and jailbroken legitimate models. Talos found that at least one heavily advertised criminal model seller had no working product, and expects LLMs to act as a force multiplier for familiar attacks rather than to create new classes of weapon.
For defenders this means two things. First, content controls on public models do not stop an attacker with a local uncensored model, so phishing, malware and fraud defences must assume AI-written content at scale. Second, your own model deployments can be the capability: an exposed or weakly governed internal model, or a model you publish, can be obtained and repurposed. The Uncensored and Abliterated AI Models guide covers the first case and the AML.T0054 LLM Jailbreak guide the second route.
What defenders can observe
Obtaining capabilities is mostly invisible. These are the points where it shows, or where obtained tooling meets your estate.
| Where | Signal | Sub-technique |
|---|---|---|
| Internet-facing AI and workflow platforms | Probing that follows public proof-of-concept releases; version checks across many hosts; requests shaped like public exploit code | .003 |
| Endpoints and servers | Agent frameworks, MCP servers or coding agents installed outside approved software; agent tool configuration that disables approvals or permission prompts | .004, .001 |
| AI provider accounts | Bursts of low-cost validation calls across many keys or models, followed by sustained invocation from unfamiliar sources | .001 (key checkers, proxies) |
| Model API gateways and security classifiers | Inputs that match known open source attack patterns; many mutated variants of one sample | .000 |
| Email, chat and web proxy logs | AI assistant URLs with prompt parameters containing words such as "remember" or "trusted source", which Microsoft recommends hunting for | Parent |
| Identity proofing | Virtual camera devices, injected video streams and face swap artefacts | .001, .002 |
Unit 42 lists agent tool settings such as permission-skipping and auto-approve modes among its indicators. The same settings on your own developers' machines are worth finding, because they remove the approval step that contains a hijacked agent.
Mitigations and hardening
ATLAS maps two mitigations: AML.M0001 Limit Model Artifact Release, to limit public release of production model artifacts that adversaries could obtain and adapt, and AML.M0022 Generative AI Model Alignment, for model developers to resist malicious requests and attempts to remove safety behaviour. Most organisations should add controls that make obtained capabilities fail:
- Patch and configure what public exploits target: require authentication on every endpoint of AI and workflow platforms, turn off auto-login and public flow access, and patch quickly after disclosures. See the AML.T0049 Exploit Public-Facing Application guide.
- Test models against public attack libraries first: run the same open source attack implementations an adversary would obtain in an authorised red team before release. See the AI Red Teaming Guide.
- Control agent tool intake: allow-list MCP servers, skills and plugins, pin versions, and keep approval prompts on. See the AI Agent Tool and Plugin Security Guide.
- Make stolen AI keys worthless quickly: owners, quotas, spend alerts, invocation logging and fast rotation. See the LLMjacking Guide.
- Limit what you release: apply AML.M0001 to production model weights and keep internal models behind authentication.
- Assume commodity deepfakes in identity proofing: use injection-resistant capture and liveness checks. See the Identity Proofing and KYC Guide.
Where identity fits
Several obtained capabilities only work with credentials. Key checkers and reverse proxies need stolen AI keys; agent tools gain their power from the tokens and service accounts they are configured with; and public exploits against workflow platforms pay off when those platforms store broad API keys. Treat AI provider keys and agent tool credentials as non-human identities with owners, narrow scopes and short lifetimes, and keep them out of workflow platform variables where possible. The AML.T0055 Unsecured Credentials guide covers where these credentials leak.
How to prepare, step by step
- Track capability releases: add ATLAS case studies, new public proofs of concept for AI and workflow platforms, and new attack library releases to threat intelligence requirements.
- Map exposure: list internet-facing AI, notebook and workflow platforms, and note which require authentication on every endpoint.
- Close the easy paths: enforce authentication, disable auto-login and public access features, and patch. Stage changes in a test environment and keep a rollback plan for each platform.
- Inventory agent tooling: find agent frameworks, MCP servers and coding agents on endpoints, and flag configurations that skip approvals.
- Red team with public tools: run open source attack libraries and public proofs of concept against non-production copies, under authorisation, and fix what works.
- Harden AI keys: add quotas, spend alerts and invocation logging, then measure time to revoke a test key.
Small organisations: authentication and patching on exposed AI and workflow platforms, plus AI key hygiene, cover most of the risk. Large organisations and model developers: add model red teaming with public libraries, AML.M0001 release reviews and agent tool intake controls.
Measuring readiness
- Share of internet-facing AI and workflow platforms requiring authentication on every endpoint (target 100%).
- Median days from public proof-of-concept release to patch for those platforms.
- Number of endpoints running agent tools with approvals disabled (target zero).
- Share of production models tested against public adversarial attack libraries before release.
- Median time to revoke a compromised AI provider key.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0016 and .000 to .004 (tactic AML.TA0003 Resource Development); mitigations AML.M0001, AML.M0022; related AML.T0017 Develop Capabilities | The technique, sub-techniques and mapped mitigations |
| MITRE ATT&CK v20 | T1588 Obtain Capabilities; T1588.002 Tool; T1588.005 Exploits | The enterprise technique this mirrors |
| OWASP Top 10 for LLM Applications 2025 | LLM03:2025 Supply Chain; LLM06:2025 Excessive Agency | Obtained agent tools and models entering your environment; over-privileged agents |
| NIST SP 800-53 Rev 5 | CM-11 User-installed Software; CM-7 Least Functionality; IA-5 Authenticator Management; SI-4 System Monitoring | Agent tool intake, reduced exposure, AI key management, monitoring |
| NIST CSF 2.0 | ID.RA-05; PR.PS-05; DE.CM-09 | Threat-informed prioritisation, unauthorised software prevented, monitoring |
Common failure patterns
- Treating public attack code as academic: research libraries and proofs of concept are exactly what adversaries obtain first.
- Slow patching of AI workflow platforms: agents now download and try public proofs of concept soon after release.
- Insecure defaults left on: the Hermes attempts failed only because targets had changed them.
- Agent tools with approvals turned off: convenience settings remove the last containment step.
- AI keys without quotas or monitoring: bulk key checkers find and monetise them quickly.
Practitioner checklist
- Add AI capability releases and ATLAS case studies to threat intelligence requirements.
- Require authentication and secure defaults on AI and workflow platforms; patch fast.
- Red team models with the public attack libraries an adversary would use.
- Allow-list and pin agent tools; keep approval prompts on.
- Give AI provider keys owners, quotas, spend alerts and rapid revocation.
- Review public releases of model artifacts (AML.M0001).
- Hunt for AI assistant links carrying prompt parameters in mail and web logs.
Standards and references
- MITRE ATLAS: AML.T0016 Obtain Capabilities
- MITRE ATT&CK: T1588 Obtain Capabilities
- MITRE ATLAS: AML.CS0070 DeepSeek-Powered Hermes Agent in Langflow and n8n Exploitation Attempts
- Palo Alto Networks Unit 42: Autonomous AI cyberattack campaign
- Cisco Talos: Cybercriminal abuse of large language models
- Microsoft Security: AI recommendation poisoning
- MITRE ATLAS: AML.CS0030 LLMjacking
- OWASP: LLM03:2025 Supply Chain
Related NHI Mgmt Group resources: T1588 Obtain Capabilities · AML.T0017 Develop Capabilities · AML.T0079 Stage Capabilities · MITRE ATLAS Mitigations Guide · MITRE ATLAS Guide