Attacks on AI systems are planned before they touch your environment: the adversary studies your models, agents and data sources, then gathers the accounts, infrastructure, artefacts and tools the attack needs. MITRE ATLAS describes these two preparatory stages as Reconnaissance (AML.TA0002), where the adversary "is trying to gather information about the AI system they can use to plan future operations", and Resource Development (AML.TA0003), where the adversary "is trying to establish resources they can use to support operations". This guide covers both tactics together because the defensive levers overlap: limit what you publish, watch the places where attackers stage resources against you, and make the probing that does reach you visible. It covers all 53 current techniques and sub-techniques in ATLAS 2026.10 and is written for AI security leads, ML platform owners and threat intelligence teams. For the framework as a whole, see the MITRE ATLAS Guide.
Key takeaways
- Preparation appears in most recorded AI attacks. Of the 77 case studies in ATLAS 2026.10, 50 include a Resource Development step and 32 include a Reconnaissance step.
- Agents now do the reconnaissance. Autonomous Reconnaissance (AML.T0116) appears in six ATLAS case studies, all incidents from 2025 and 2026, including the GTG-1002 campaign in which agents mapped targets at machine speed.
- Your leaked credentials become their resources. AI Service Proxies (AML.T0008.005) pool stolen AI API keys behind reverse proxies and resell access, which makes key hygiene a Resource Development control.
- Public registries are the staging ground. Poisoned models, datasets and agent tools (AML.T0115), staged capabilities (AML.T0079) and hallucinated package names (AML.T0060) are all published where your developers download from.
- Information release is the most mapped mitigation. Limit Public Release of Information (AML.M0000) is linked to 11 of the 53 entries, and AI Honeypots (AML.M0039) to 10, making disclosure discipline and deception the two broadest controls.
What the two tactics mean for AI systems
Both tactics mirror the ATT&CK Enterprise tactics of the same names (TA0043 and TA0042), and many ATLAS techniques carry an explicit ATT&CK reference, for example Search Victim-Owned Websites (AML.T0003 and T1594) and Establish Accounts (AML.T0021 and T1585). What ATLAS adds is the AI-specific target set: model architectures and families, training datasets, RAG data sources, agent configurations and trigger channels, and AI service accounts. The ATT&CK view of preparation is covered in the ATT&CK Resource Development Tactic Guide; this page covers what changes when the target is an AI system.
- Reconnaissance (18 entries): passive research in papers, pre-prints, blogs, code repositories, application stores and victim websites; scan databases such as Shodan and Censys; active scanning of hosted AI resources, platform metadata APIs and agent trigger channels; identifying the sources a RAG system indexes; gathering identity information; and fully autonomous agent-driven reconnaissance.
- Resource Development (35 entries): acquiring public models, datasets and agent configurations; replicating model behaviour to build a proxy for offline attack development; acquiring or compromising infrastructure (development workspaces, domains, serverless, AI service proxies, physical countermeasures); obtaining or developing capabilities including adversarial attack code, exploits, malware and agent tools; establishing or compromising accounts; and publishing poisoned artefacts or entities that match AI hallucinations.
Replicate AI Model Behavior (AML.T0005) sits in both Resource Development and AI Attack Adaptation (AML.TA0001): a proxy model is a resource the attacker builds, and also the means of adapting attacks before using them against the real model. See the ATLAS AI Attack Adaptation Tactic.
Which techniques matter most
The counts below are the number of ATLAS 2026.10 case studies whose procedure employs the technique or one of its sub-techniques, computed from the ATLAS YAML release. They show where recorded activity concentrates, not overall prevalence.
| Technique family | Tactic | Case studies | Why it matters to defenders |
|---|---|---|---|
| AML.T0017 Develop Capabilities | Resource Development | 20 | Adversarial attack code, autonomous exploit development and agent tools are built offline; you see only the result, so model robustness and testing carry the defence |
| AML.T0008 Acquire Infrastructure | Resource Development | 15 | Includes AI service proxies built on stolen keys and lookalike domains used in later phishing or exfiltration |
| AML.T0079 Stage Capabilities | Resource Development | 13 | Payloads, prompts and tools are placed on infrastructure or public platforms that your agents and users may later fetch |
| AML.T0002 Acquire Public AI Artifacts | Resource Development | 12 | Every model, dataset and agent configuration you publish is attack-development material |
| AML.T0000 Search Open Technical Databases | Reconnaissance | 10 | Papers, blogs and scan databases reveal model families and exposed AI services |
| AML.T0021 Establish Accounts | Resource Development | 10 | Bulk or fraudulent AI service accounts power distillation, abuse and registry impersonation |
| AML.T0115 Publish Poisoned AI Artifacts | Resource Development | 9 | Malicious models, datasets and agent tools in public registries are a direct supply chain risk |
| AML.T0116 Autonomous Reconnaissance | Reconnaissance | 6 | Speed and parallelism compress the time between exposure and attack |
How adversaries chain preparation into attack
- Agent-driven mapping, then intrusion: in the Anthropic GTG-1002 campaign, a group Anthropic assesses as Chinese state-sponsored used Claude Code connected to security tools through the Model Context Protocol to map target infrastructure and services in parallel against about 30 organisations; Anthropic reported that the AI performed 80 to 90 percent of tactical operations. ATLAS records this as case study AML.CS0069 and maps it to AML.T0116.
- Stolen keys turned into resale infrastructure: the LLMjacking pattern starts with cloud or AI API keys taken from compromised servers or found in public code, which are validated quietly and then placed behind reverse proxies such as OAI Reverse Proxy. Sysdig estimated costs to victims of over $46,000 per day for one model family. ATLAS maps its LLMjacking case study (AML.CS0030) to AML.T0008.005 AI Service Proxies.
- Scanning for exposed AI infrastructure: in ShadowRay, attackers found Ray dashboards reachable from the internet, typically on port 8265, and used the unauthenticated Jobs API (CVE-2023-48022, disputed by the maintainer) to run code; stolen material included OpenAI, Hugging Face, Stripe and Slack tokens and cloud credentials. Oligo Security reported about 500 exposed IP addresses. This is the kind of exposure that AML.T0000.003 Scan Databases and AML.T0006.002 Scan for Exposed AI Infrastructure describe.
- Poisoned artefacts waiting in registries: ATLAS case studies such as Malicious Models on Hugging Face (AML.CS0031) and Model Namespace Reuse Supply Chain Attack (AML.CS0065) show attackers publishing models where victims will pull them, and Poisoned Postmark MCP Server Email Exfiltration (AML.CS0053) shows the same with an agent tool.
Where identity fits
Identity runs through both tactics. Gather Victim Identity Information (AML.T0087) collects names, email addresses and sometimes credentials for later phishing or deepfake-assisted fraud. Establish Accounts (AML.T0021) and Compromise Accounts (AML.T0139) give attackers platform identities, including accounts on model registries that impersonate your organisation. Acquire Public AI Artifacts: AI Agent Configuration (AML.T0002.002) targets agent configuration files that can contain credentials for external services. And every AI API key or cloud key you leak becomes a resource in someone else's proxy pool. The controls are those of non-human identity management: no static keys in code or agent configuration, short-lived workload credentials, per-project scoping and spend limits on AI keys, secret scanning of public repositories, and rapid revocation. See the LLMjacking Guide and the AI API key abuse analysis.
Mitigation priorities
Counting ATLAS "mitigates" relationships that target the 53 entries gives the following ranking. Most preparation happens outside your environment, so the mitigations shift towards what you publish, what you expose and what you can observe.
| ATLAS mitigation | Entries linked (of 53) | What to do |
|---|---|---|
| AML.M0000 Limit Public Release of Information | 11 | Review papers, blogs, job posts, documentation and code for details of production model families, data sources, agent tools and infrastructure before release |
| AML.M0039 AI Honeypots | 10 | Deploy decoy AI endpoints, agent trigger addresses and canary AI keys; any interaction is a high-confidence signal of reconnaissance or key misuse |
| AML.M0001 Limit Model Artifact Release | 7 | Do not publish production checkpoints, training data or representative models without a risk decision |
| AML.M0042 Threat Intelligence Program | 6 | Track registry impersonation, lookalike domains, leaked keys and agent-driven campaigns relevant to your AI stack |
| AML.M0016 Vulnerability Scanning | 4 | Scan downloaded model files, for example pickle-based formats, for unsafe calls before loading |
| AML.M0019 Control Access to AI Models and Data in Production and AML.M0043 AI Agent External Resource Lifecycle Management | 3 each | Authenticate every model endpoint; treat resources agents create as owned, lifecycle-managed assets |
| AML.M0004 Limit AI Service Query Volume and Rate | 2 | Rate, burst and quota limits per identity raise the cost of replicating model behaviour |
Detection: making preparation visible
Only some of these techniques touch your systems. Focus detection on the ones that do and use external monitoring for the rest.
| Technique | Visible to you? | Signal or check |
|---|---|---|
| AML.T0006 Active Scanning (hosted AI resources, metadata APIs, exposed infrastructure, agent trigger channels) | Yes | Gateway and API logs showing enumeration of model endpoints, unauthenticated requests to AI services, crafted messages to agent email or webhook triggers; decoy endpoints |
| AML.T0005 Replicate AI Model Behavior | Partly | High-volume, systematic query patterns from one identity or a cluster of new accounts against inference APIs |
| AML.T0021 Establish Accounts and AML.T0139 Compromise Accounts | Partly | Bulk sign-ups with shared attributes on your AI service; registry organisations or accounts imitating your brand |
| AML.T0008.005 AI Service Proxies | Yes, through your keys | First-time model enablement, invocation from new networks, logging disabled, spend anomalies on AI keys |
| AML.T0115, AML.T0079, AML.T0060 | No, external | Monitor registries for lookalike namespaces and packages; scan and pin artefacts before use |
| AML.T0000, AML.T0003, AML.T0004, AML.T0095, AML.T0064 | No, external | Self-audit: what can be learned about your models, data sources and agents from public material, including scan databases |
Implementation roadmap
- Run an exposure self-assessment. Search scan databases, code repositories, app stores and your own publications for your AI endpoints, model families, RAG sources, agent configurations and keys. Record what an attacker could learn.
- Close the exposed infrastructure. Put AI dashboards, notebooks, inference servers and orchestration APIs behind authentication and network controls; rotate any credential found on an exposed system.
- Fix key hygiene. Replace static AI and cloud keys with workload identity where supported, scope remaining keys per project, set spend limits, keep model invocation logging on and alert on logging changes.
- Set a release review. Add AML.M0000 and AML.M0001 checks to the publication process for papers, model cards, blogs and open-source releases. Pilot it with one research team before making it mandatory.
- Deploy deception. Place canary AI keys in likely leak locations and decoy model endpoints or agent trigger addresses; route interactions straight to the SOC.
- Control what comes in. Allow models, datasets and agent tools only from approved sources, pinned by version and hash, and scanned before loading. See the Model Supply Chain Guide.
A small team can do steps 1 to 3 in a few weeks with built-in cloud and AI platform controls. Larger organisations with research publication programmes and many teams consuming public models need steps 4 to 6 as formal processes owned by the AI security function.
Measuring progress
- Exposed AI services: count of internet-reachable AI endpoints, dashboards or APIs without authentication, trending to zero.
- Leaked AI key dwell time: hours from an AI or cloud key appearing publicly to its revocation.
- Static AI keys remaining: number of long-lived AI service keys versus workload identity integrations.
- Artefact provenance coverage: share of models and agent tools in production pulled from approved, pinned and scanned sources.
- Honeypot interactions: number and time to triage of decoy endpoint and canary key hits.
Common failure patterns
- Publishing the production recipe: a detailed paper or blog naming the exact model family, data sources and tools gives attackers a target profile.
- AI infrastructure on the internet: notebooks, Ray dashboards and inference servers left reachable without authentication are found by scan databases quickly.
- Keys in agent configuration files: configuration committed to repositories exposes credentials for every tool the agent uses.
- Trusting registry names: pulling a model or tool by name without checking the publisher, version and hash lets namespace reuse and impersonation succeed.
- No query limits on inference APIs: unlimited querying lets an adversary replicate behaviour to build a proxy model for offline attack development.
Every technique in both tactics
All 53 current entries in ATLAS 2026.10 (18 Reconnaissance, 35 Resource Development). Technique guides are linked where they exist; sub-techniques are covered on their parent's guide.
| ID and name | Tactic | Sub-techniques | Guide |
|---|---|---|---|
| AML.T0000 Search Open Technical Databases | Reconnaissance | .000 Journals and Conference Proceedings, .001 Pre-Print Repositories, .002 Technical Blogs, .003 Scan Databases | AML.T0000 Search Open Technical Databases |
| AML.T0001 Search Open AI Vulnerability Analysis | Reconnaissance | None | AML.T0001 Search Open AI Vulnerability Analysis |
| AML.T0003 Search Victim-Owned Websites | Reconnaissance | None | AML.T0003 Search Victim-Owned Websites |
| AML.T0004 Search Application Repositories | Reconnaissance | None | AML.T0004 Search Application Repositories |
| AML.T0006 Active Scanning | Reconnaissance | .000 Enumerate Hosted AI Resources, .001 Query Platform Metadata APIs, .002 Scan for Exposed AI Infrastructure, .003 Probe AI Agent Trigger Channels | AML.T0006 Active Scanning |
| AML.T0064 Gather RAG-Indexed Targets | Reconnaissance | None | AML.T0064 Gather RAG-Indexed Targets |
| AML.T0087 Gather Victim Identity Information | Reconnaissance | None | AML.T0087 Gather Victim Identity Information |
| AML.T0095 Search Open Websites/Domains | Reconnaissance | .000 Code Repositories | AML.T0095 Search Open Websites/Domains |
| AML.T0116 Autonomous Reconnaissance | Reconnaissance | None | AML.T0116 Autonomous Reconnaissance |
| AML.T0002 Acquire Public AI Artifacts | Resource Development | .000 Datasets, .001 Models, .002 AI Agent Configuration | AML.T0002 Acquire Public AI Artifacts |
| AML.T0005 Replicate AI Model Behavior | Resource Development, AI Attack Adaptation | .000 Replicate Behavior from Gathered AI Artifacts, .001 Replicate Behavior from Model Outputs, .002 Adapt Existing Model to Replicate Behavior | AML.T0005 Replicate AI Model Behavior |
| AML.T0008 Acquire Infrastructure | Resource Development | .000 AI Development Workspaces, .001 Consumer Hardware, .002 Domains, .003 Physical Countermeasures, .004 Serverless, .005 AI Service Proxies | AML.T0008 Acquire Infrastructure |
| AML.T0016 Obtain Capabilities | Resource Development | .000 Adversarial AI Attack Implementations, .001 Software Tools, .002 Generative AI, .003 Exploits, .004 AI Agent Tools | AML.T0016 Obtain Capabilities |
| AML.T0017 Develop Capabilities | Resource Development | .000 Adversarial AI Attacks, .001 Autonomous Exploit Development, .002 AI Agent Tools, .003 Malware | AML.T0017 Develop Capabilities |
| AML.T0021 Establish Accounts | Resource Development | None | AML.T0021 Establish Accounts |
| AML.T0060 Publish Hallucinated Entities | Resource Development | None | AML.T0060 Publish Hallucinated Entities |
| AML.T0079 Stage Capabilities | Resource Development | None | AML.T0079 Stage Capabilities |
| AML.T0115 Publish Poisoned AI Artifacts | Resource Development | .000 Datasets, .001 Models, .002 AI Agent Tools | AML.T0115 Publish Poisoned AI Artifacts |
| AML.T0128 Compromise Infrastructure | Resource Development | None | AML.T0128 Compromise Infrastructure |
| AML.T0139 Compromise Accounts | Resource Development | None | AML.T0139 Compromise Accounts |
Framework mapping
| Framework | Mapping |
|---|---|
| MITRE ATT&CK v20 | Reconnaissance TA0043 and Resource Development TA0042; ATLAS references include T1596, T1594, T1593, T1589, T1595, T1583, T1584, T1585, T1586, T1587 and T1588 |
| OWASP Top 10 for LLM Applications 2025 | LLM03:2025 Supply Chain (poisoned models, datasets and tools); LLM10:2025 Unbounded Consumption (model replication through unrestricted querying); LLM02:2025 Sensitive Information Disclosure (what public material and outputs reveal) |
| NIST CSF 2.0 | ID.RA-01 vulnerabilities identified; PR.AA-01 identities and credentials managed; GV.SC-07 supplier risk monitored; DE.CM-01 networks monitored |
Practitioner checklist
- Audit public material and scan databases for what they reveal about your models, data sources and agents.
- Require authentication and network restriction on every AI dashboard, notebook, inference server and orchestration API.
- Remove static AI keys from code and agent configuration; scope, spend-limit and monitor the rest.
- Keep model invocation logging on and alert on logging changes and first-time model enablement.
- Apply rate, burst and quota limits per identity on inference APIs.
- Pull models, datasets and agent tools only from approved, pinned and scanned sources.
- Monitor registries and domains for lookalikes of your organisation and packages.
- Deploy canary AI keys and decoy AI endpoints with alerts to the SOC.
- Add an AI disclosure review to publication and open-source release processes.
Standards and references
- MITRE ATLAS: Reconnaissance (AML.TA0002)
- MITRE ATLAS: Resource Development (AML.TA0003)
- MITRE ATLAS: Autonomous Reconnaissance (AML.T0116)
- MITRE ATLAS: Publish Poisoned AI Artifacts (AML.T0115)
- MITRE ATLAS: Limit Public Release of Information (AML.M0000)
- MITRE ATT&CK: Reconnaissance (TA0043)
- OWASP: LLM03:2025 Supply Chain
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: MITRE ATLAS Guide · ATT&CK Resource Development Tactic Guide · AI Supply Chain and AI-BOM Guide · Slopsquatting and Package Hallucination Guide · Hugging Face Security Guide