AML.T0002 Acquire Public AI Artifacts

The datasets, model checkpoints and agent configuration files you publish, or leave reachable, are the raw material an adversary uses to build an attack against your production AI. MITRE ATLAS records this as AML.T0002 Acquire Public AI Artifacts, a Resource Development (AML.TA0003) technique rated Realized, with three sub-techniques: Datasets (AML.T0002.000), Models (AML.T0002.001) and AI Agent Configuration (AML.T0002.002). This guide explains what the technique covers in the ATLAS 2026.10 release, the cases ATLAS records, what you can and cannot see, and how to reduce what an adversary can take. It is for ML engineers, AI platform owners, agent developers and security teams that publish models or data, or run agents whose configuration lives in repositories. Finding the artefacts is a separate step, covered in AML.T0004 Search Application Repositories and AML.T0003 Search Victim-Owned Websites; this page starts at the point of acquisition.

Key takeaways

It is preparation, not intrusion. ATLAS places AML.T0002 in Resource Development: the adversary collects material to build a surrogate model, craft adversarial inputs or harvest secrets later.
Representative is enough. ATLAS notes adversaries want your own artefacts most, but artefacts representative of yours (the same architecture, a similar dataset) still let them tailor an attack.
Agent configuration is the newest and most direct risk. AML.T0002.002, added in April 2026, covers MCP configs, system prompts, skills and environment files, which can hold credentials and tool definitions.
Hosting your own artefacts gives you a log. ATLAS observes that artefacts on victim-controlled infrastructure give the victim some information on who accessed them; public hubs give you very little.
ATLAS maps two mitigations. AML.M0000 Limit Public Release of Information and AML.M0001 Limit Model Artifact Release, both about deciding deliberately what leaves the organisation.

What the technique covers

ATLAS describes AML.T0002 as searching public sources, including cloud storage, public-facing services and software or data repositories, to identify AI artefacts: the software stack used to train and deploy models, training and testing data, model configurations and parameters. Artefacts associated with the victim organisation are of most interest because they may represent what runs in production. Some artefacts require registration, cloud keys or written requests, in which case the adversary may first use AML.T0021 Establish Accounts.

ATLAS names two main downstream uses. Artefacts help the adversary replicate the model's behaviour (AML.T0005 Replicate AI Model Behavior), and if they include pieces of the actual production model they can be used directly to craft adversarial data (AML.T0043 Craft Adversarial Data). The 2026 sub-technique adds a third: agent configuration leads straight to discovery of agent capabilities and to credential theft.

Sub-technique	Maturity (2026.10)	What is acquired	Typical follow-on
AML.T0002.000 Datasets	Demonstrated	Public datasets used by the victim or representative of its data, in cloud storage or on victim-owned websites; some need an account	Training a surrogate model; staging and tailoring evasion or poisoning attacks
AML.T0002.001 Models	Demonstrated	Model architectures and pre-trained weights; ATLAS lists configuration formats such as YAML or Python files and storage formats such as ONNX (.onnx), HDF5 (.h5), Pickle (.pkl), PyTorch (.pth) and TensorFlow (.pb, .tflite)	Offline crafting of adversarial inputs; modifying the model for a later supply chain attack
AML.T0002.002 AI Agent Configuration	Demonstrated	System prompts, tool configuration (ATLAS cites `mcp.json`, `claude_desktop_config.json`, `.claude/settings.json`, `.vscode/tasks.json`), skills and workflows, environment and deployment configs	Discover AI Agent Configuration (AML.T0084); AML.T0083 Credentials from AI Agent Configuration

The parent technique is rated Realized and applies to predictive, generative and agentic AI platforms. ATLAS has no direct ATT&CK counterpart for this technique.

Cases in ATLAS

ATLAS maps AML.T0002 or one of its sub-techniques to more than ten case studies. Most are research exercises; they show the pattern consistently: acquiring public artefacts is how an attack on a model that the adversary cannot see from inside starts.

Case study	Sub-technique	What was acquired and why
AML.CS0007 GPT-2 Model Replication	.000 and .001	Researchers recreated the GPT-2 training dataset from OpenAI's published documentation and used a similar public model (Grover) as a reference implementation, replicating the model before the full version was released
AML.CS0005 Attack on Machine Translation Services	.000 and .001	Researchers gathered datasets and model architectures similar to those the target translation services used
AML.CS0011 Microsoft Edge AI Evasion	Parent	The team obtained the publicly available base model to use against the target model
AML.CS0013 Backdoor Attack on Deep Learning Models in Mobile Apps	.001	Models were extracted from app packages downloaded from Google Play after filtering for TensorFlow and TFLite formats
AML.CS0019 PoisonGPT	.001	Researchers pulled GPT-J-6B from Hugging Face, modified it to return a false fact and re-uploaded it, showing the step before a model repository supply chain attack
AML.CS0006 ClearviewAI Misconfiguration	Parent	A misconfigured source repository exposed credentials, cloud storage keys for 70K video samples and application copies; ATLAS notes an adversary could have downloaded training data and learned the models and capabilities
AML.CS0064 Poisoned GGUF Templates	.001	The adversary obtains a legitimate open-weight model artefact with a bundled chat template, chosen because downstream users are likely to keep that template
AML.CS0051 OpenClaw Command and Control via Prompt Injection	.002	Researchers acquired agent configurations useful for developing an indirect prompt injection attack against the agent

The Lasso Security research on exposed Hugging Face tokens shows the same risk from the credential side. According to the Hugging Face API Tokens Exposed 2023 page, 1,681 valid tokens left in public repositories gave read access to more than 10,000 private models across 723 organisations, and 655 tokens had write permission. A leaked token turns private artefacts into acquirable ones, and write permission turns acquisition into a supply chain risk.

Where identity and secrets fit

AML.T0002.002 is an identity problem as much as a model problem. ATLAS says agent configuration files define what tools an agent can use, credentials for external services, system prompts and behavioural settings. An mcp.json committed to a public repository with an API key in an env block publishes a non-human identity together with a list of what it can reach. The fix is the same as for any secret in code: keep credentials out of configuration files, reference them from a secrets manager or the operating system keychain, scan repositories before they are public, and revoke rather than delete when one leaks. See the MCP Static Token Audit and Coding Agent Configuration File Attacks. For datasets and models behind registration or keys, the access tokens you issue to researchers and partners are also non-human identities: scope them to the specific artefact, give them an expiry and log their use.

Reducing what can be acquired

ATLAS maps two mitigations. AML.M0000 Limit Public Release of Information asks organisations to limit the release of sensitive information in the metadata of deployed systems and publicly available applications. AML.M0001 Limit Model Artifact Release says that limiting release of datasets reduces an adversary's ability to target production models trained on the same or similar data, and that limiting release of model architectures and checkpoints reduces the ability to target those models. In practice that means a release decision for every artefact, not a blanket ban.

Control	Applies to	Detail
Release review for AI artefacts	.000, .001	Before a dataset, checkpoint or model card goes public, record whether it is the production artefact, a representative one or unrelated, and who approved it (AML.M0001)
Separate research and production lineage	.001	Publish research checkpoints that differ in data or fine-tuning from the production model, so a public copy is not a full copy of what you serve
Trim metadata	All	Remove internal model names, version strings, data source paths and framework detail from public model cards, app packages and API error messages (AML.M0000)
Private by default on model hubs	.000, .001	Organisation repositories private unless approved; gated access with named, expiring tokens for partners. See the Hugging Face Security Guide
Authenticated, logged storage	.000, .001	No anonymous object storage for training data or weights; access logging on so downloads are attributable
Agent config hygiene	.002	Exclude agent config directories and `.env` files from public repositories, keep secrets out of config, and pre-commit and server-side secret scanning on repositories that hold agent configs
Assume published means acquired	All	For any artefact that must stay public, test the production model for robustness on the assumption the adversary holds a close surrogate

Decision guidance: open publication of models and datasets is often a deliberate scientific or commercial choice, and ATLAS does not suggest stopping it. The question is whether a public artefact is close enough to a security-relevant production model (fraud, content moderation, malware detection, identity verification) that holding it gives an adversary an offline test bench. If it is, keep the production lineage private or add robustness testing that assumes white-box access. A small team should start with two things: no credentials in agent configuration, and no anonymous storage for weights or data. A large organisation publishing many artefacts needs a register of what has been released, by whom, and how it relates to production systems; the AI Supply Chain and AI-BOM Guide covers the record keeping.

What you can detect

Downloads from public hubs and code hosts are invisible to you. Detection therefore focuses on infrastructure you control and on your own exposure.

Where	What to watch	Why it matters
Your object storage and download portals	Bulk or repeated downloads of datasets and weights, new accounts that download immediately after registering, access from unexpected networks	ATLAS notes victim-hosted artefacts give some information on who accessed them
Model hub organisation audit logs	Visibility changes from private to public, new members, token creation with write scope	A visibility change or leaked token turns private artefacts into public ones
Public code hosts	Secret scanning alerts and searches for your organisation name plus agent config file names	Finds AML.T0002.002 exposure before an adversary does
Inference APIs	Query patterns consistent with probing or testing crafted inputs after a public release	Acquired artefacts are usually followed by model replication or adversarial testing
Credential use	Use of a key that appeared in a public config, from any source address	Confirms harvesting from published configuration

How to put it in place

Inventory: list every public dataset, model, model card, notebook and repository containing agent configuration that your organisation publishes or hosts.
Classify: mark each as production, representative or unrelated, and identify which production models are security-relevant.
Self-search: look for your own artefacts the way an outsider would, including agent config file names in public code, and record what you find.
Remediate in order: revoke and rotate any credential found first, then make unapproved artefacts private, then trim metadata.
Install the release gate: require a recorded release decision for new AI artefacts, with secret scanning on every repository that may become public.
Test and roll back: after a visibility change, confirm from outside that the artefact is no longer reachable; if a change breaks a partner, restore access through named, expiring tokens rather than reopening public access.

Measuring it

Share of public AI artefacts with a recorded release decision (target 100%).
Credentials found in public agent configuration files per quarter, and median time to revocation.
Number of storage locations serving datasets or weights without authentication (target zero).
Share of security-relevant production models whose robustness has been tested on the assumption of an adversary-held surrogate.
Number of model hub tokens with write scope and no expiry.

Common failure patterns

Publishing production by accident: the "research" checkpoint on a public hub is the one serving customers.
Secrets in agent config: MCP and IDE configuration committed with API keys in plain text, so acquiring the file is acquiring the credential.
Open buckets for training data: object storage made public for a partner hand-over and never closed.
Long-lived write tokens: hub tokens with write permission left in notebooks and repositories, as in the Lasso findings.
Deleting instead of revoking: removing a leaked file from the repository while the credential in its history stays valid.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0002, .000, .001, .002 (AML.TA0003 Resource Development)	The technique and its sub-techniques
MITRE ATLAS mitigations	AML.M0000 Limit Public Release of Information; AML.M0001 Limit Model Artifact Release	The mitigations ATLAS maps to this technique
MITRE ATLAS related techniques	AML.T0005, AML.T0043, AML.T0021, AML.T0084, AML.T0083	Prerequisites and follow-on steps named in the technique text
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement; SC-28 Protection of Information at Rest; CM-8 System Component Inventory	Access to model and data stores, protecting weights at rest, knowing what you have published
NIST CSF 2.0	ID.AM-02; PR.DS-01	Inventory of software and services; protection of data at rest
OWASP Top 10 for LLM Applications 2025	LLM02 Sensitive Information Disclosure	Leakage of prompts, configuration and credentials

Practitioner checklist

Keep a register of every AI artefact the organisation has made public, with its relationship to production.
Require a recorded release decision before any dataset, checkpoint or model card is published.
Keep model hub repositories private by default and use named, expiring tokens for partners.
Serve weights and training data only from authenticated storage with access logging.
Keep credentials out of MCP, IDE and agent configuration files; reference a secrets manager instead.
Run secret scanning on every repository that holds agent configuration.
Revoke and rotate any credential found in a public artefact, then clean history.
Test security-relevant models assuming the adversary holds a close surrogate.

AML.T0002 Acquire Public AI Artifacts: How the Technique Works Against AI Systems and How to Defend