AML.T0079 Stage Capabilities: Spotting Malicious AI Payloads Staged on Trusted Infrastructure

Before an attacker can poison your agent or your model pipeline, the payload has to be sitting somewhere your AI systems will reach: a web page, a model hub repository, a code repository or a link that opens an assistant. MITRE ATLAS records this preparation step as AML.T0079 Stage Capabilities, a Resource Development (AML.TA0003) technique in which adversaries upload, install or set up capabilities they developed or obtained, on infrastructure they bought or compromised, or on web services such as GitHub, model registries such as Hugging Face, and container registries. Its ATT&CK counterpart is T1608 Stage Capabilities; this guide covers only the AI-specific angle. It explains what gets staged for AI attacks, the ATLAS cases that show it, how defenders can see staged content before or as it is consumed, and the intake controls that stop it. It is for threat intelligence, AI platform and detection teams.

Key takeaways

• Staged AI payloads are mostly data, not binaries. ATLAS lists poisoned datasets, malicious models and prompt injections; the published cases add web pages written for agents, rules files, pre-filled assistant links and exfiltration endpoints.
• Trusted platforms are the preferred shelf. Model hubs, code hosting, established domains and AI assistant domains make staged content look normal to people and to URL reputation checks.
• Names are part of the payload. ATLAS notes staging under legitimate company or product names, typosquats and hallucinated names that models tend to invent.
• You see staging at the point of intake. Most staging happens outside your estate, so the practical controls sit where your systems pull artefacts, fetch pages or follow links: allowlists, verification, scanning and logging.
• Exfiltration endpoints are staged too. In several ATLAS cases the staged capability was a server waiting to receive data, which makes egress control from AI systems a staging defence.

What the technique covers

ATLAS places AML.T0079 after the adversary has a capability, built under AML.T0017 Develop Capabilities or obtained under AML.T0016 Obtain Capabilities, and after it has somewhere to host it, through AML.T0008 Acquire Infrastructure or by taking over someone else's systems, which ATLAS records separately as AML.T0128 Compromise Infrastructure. Staging is the act of putting the capability in place so a later technique can use it: a drive-by page for AML.T0078 Drive-by Compromise, a model or dataset for AML.T0115 Publish Poisoned AI Artifacts, or a collection server for exfiltration.

ATT&CK v20 has a closely related sub-technique, T1608.007 AI Result Poisoning, in which adversaries manipulate public web content so that AI systems and AI-powered search retrieve, cite or recommend attacker-controlled information. That is one form of staged content aimed at AI, and it is a reason to treat answers built from web retrieval as untrusted input in your own systems.

What gets staged, and where

Cases that show the pattern

• Rules File Backdoor (AML.CS0041): Pillar Security staged a JavaScript file on a public website and showed that a shared AI coding assistant rules file, with instructions hidden using invisible Unicode characters, could make Cursor and GitHub Copilot add a script tag pointing at it, without mentioning the change. Pillar notes rules files spread through public directories, pull requests, templates and forks. GitHub added a warning on github.com for files containing hidden Unicode text on 1 May 2025.
• AI Recommendation Poisoning (AML.CS0072): Microsoft Defender researchers found, over about 60 days of email URL telemetry, more than 50 distinct prompt examples from 31 companies that staged "Summarize with AI" buttons and links which opened an assistant with a pre-filled prompt asking it to treat the company as a trusted source. Microsoft notes public tooling, including an npm package and website plugins, made this easy, and that all cases involved legitimate businesses rather than threat actors.
• OpenClaw command and control (AML.CS0051): HiddenLayer stored prompt injections, a script and a task list on its own website; once an agent summarised the page, the agent kept polling that site for new tasks.
• AI in the Middle (AML.CS0061): Check Point Research staged a newly registered, AI-assisted fan site that returned commands only when a specific URL parameter was present, and showed that web AI services with browsing could relay them to malware without any API key or account.
• ZombieAgent (AML.CS0066): Radware prepared a domain with a fixed set of pre-built URLs so an assistant could leak data by opening URLs exactly as given rather than constructing new ones. Radware reports OpenAI fixed the issue on 16 December 2025.
• Storm-2139 (AML.CS0057): ATLAS records that the group staged and operated a reverse proxy service so other users could reach abused generative AI services. See the Microsoft Azure OpenAI abuse by Storm-2139 breach page for the stolen API key side of that case.

How defenders can see staged content

Staging is visible in two places: externally, where you can watch for content that names or targets your organisation, and internally, at the moment your systems consume it.

Hugging Face documents that the Hub scans every repository file under 2 GB with ClamAV at each commit and shows an "ok" or "infected" badge per file, with a warning on the repository page if any file is flagged. Treat such platform verdicts as one input: they are not a substitute for your own intake scanning and verification. See the Hugging Face Security Guide.

Mitigations and intake controls

ATLAS 2026.10 maps one mitigation directly to AML.T0079: AML.M0043 AI Agent External Resource Lifecycle Management, which treats external resources that AI agents create or acquire as attributable, lifecycle-managed assets. Because most staging happens outside the victim, the other useful controls apply the ATLAS mitigations for the techniques that consume staged content.

• Approved sources only: pull models, datasets, rules files, skills and MCP servers from an allowlist of publishers or an internal mirror, never directly from search results or assistant suggestions.
• Verify artefacts (AML.M0014 Verify AI Artifacts): pin versions and check cryptographic hashes; use signatures where publishers provide them (AML.M0013 Code Signing).
• Scan before use (AML.M0016 Vulnerability Scanning): scan model files, especially serialised formats such as pickle, for unsafe calls, and scan rules and prompt files for invisible Unicode.
• Record what you consume (AML.M0023 AI Bill of Materials): keep an AI-BOM so that when a staged artefact is reported you can find where it landed. See the AI Supply Chain and AI-BOM Guide.
• Treat fetched content as untrusted (AML.M0030): restrict agent tool invocation after web content enters the context, so a staged page cannot trigger code execution or exfiltration.
• Block the collection side: egress allowlists for agents and AI workloads, and no rendering of model-chosen images or links to arbitrary hosts, deny staged exfiltration endpoints their data.
• Watch your names: monitor for lookalike organisations and packages on model hubs and code hosting, and register defensive names where practical. See the Typosquatting and Lookalike Domains Guide and the Slopsquatting and Package Hallucination Guide.

Where to start by organisation size

A small team consuming a few public models should focus on an approved-source list, hash pinning and keeping agents off machines with production secrets. A large organisation with internal model registries and many agents should run an internal mirror with mandatory scanning, an AI-BOM, external brand monitoring on model hubs and code hosting, and central logging of agent fetches. Organisations that publish their own models or datasets should also monitor for impersonating repositories that copy their names.

Where identity fits

Staging often relies on credentials. Attackers who compromise a maintainer's model hub or code hosting token can stage content under a trusted publisher name, and the Storm-2139 case shows stolen AI service API keys being turned into a resold service. Use scoped, short-lived tokens for publishing to model hubs and registries, require MFA for publisher accounts, and scan code and notebooks for exposed AI service keys.

How to test your intake

1. Map intake paths: list every way models, datasets, rules files, skills and MCP servers enter your environment, including developer laptops.
2. Stage a benign test artefact: in a controlled internal repository, publish a test model or rules file with a harmless marker (an unpinned version, a hash mismatch, invisible Unicode characters in a comment) and confirm each intake path blocks or flags it.
3. Test the agent path: point an agent at an internal test page with harmless canary instructions and confirm tool restriction or approval engages and the event is logged.
4. Test external monitoring: confirm your brand monitoring would detect a new repository or package using your organisation's name.
5. Record and repeat: keep results as regression tests and rerun after tooling changes. Roll back a rule only after the test still passes without it.

Measuring whether it works

• Intake coverage: percentage of AI artefacts consumed through the approved mirror or allowlist.
• Verification: percentage of production models and datasets with pinned versions and recorded hashes in the AI-BOM.
• Scan coverage: percentage of model files, rules files and skills scanned before first use.
• External watch: time from creation of a lookalike repository or package to detection.
• Egress control: percentage of agent hosts and AI workloads behind an egress allowlist.

Framework mapping

Common failure patterns

• Trusting the platform name: treating anything on a well-known model hub or code host as safe because the domain is reputable.
• Rules and prompt files outside review: AI configuration files copied from public directories without the review applied to code, so hidden instructions pass unseen.
• Unpinned pulls: pipelines that fetch the latest version of a model or dataset by name, so a replaced artefact flows straight in.
• Assistant-suggested packages installed directly: developers installing names an assistant produced without checking the publisher, the gap hallucinated-name staging relies on.
• Open egress from AI hosts: agents and notebooks able to reach any domain, so staged collection endpoints receive data.

Practitioner checklist

• Inventory every intake path for models, datasets, rules files, skills and MCP servers.
• Pull AI artefacts only from an allowlist or internal mirror.
• Pin versions and verify hashes or signatures before use.
• Scan model files and AI configuration files, including for invisible Unicode, before first use.
• Maintain an AI-BOM that records source, version and hash.
• Restrict agent tools after untrusted web content enters the context.
• Apply egress allowlists to agent hosts and AI workloads.
• Monitor model hubs and code hosting for lookalikes of your names.
• Hunt URL telemetry for AI assistant links with memory-manipulation prompts.

Standards and references

• MITRE ATLAS: AML.T0079 Stage Capabilities
• MITRE ATT&CK: T1608 Stage Capabilities
• OWASP: LLM03:2025 Supply Chain
• Hugging Face: Malware scanning
• Microsoft Security: Manipulating AI memory for profit, the rise of AI Recommendation Poisoning
• Pillar Security: Rules File Backdoor in GitHub Copilot and Cursor
• Check Point Research: AI in the Middle, web-based AI services as C2 proxies
• Radware: ZombieAgent

Related NHI Mgmt Group resources: MITRE ATLAS Guide · MITRE ATLAS AML.T0109 AI Supply Chain Rug Pull · MITRE ATLAS AML.T0111 AI Supply Chain Reputation Inflation · OWASP LLM Top 10 LLM03 Supply Chain Guide