ATLAS AML.T0005 Replicate AI Model Behavior Guide

An adversary does not need your model weights to own a working copy of your model: they can train one that behaves like it. MITRE ATLAS tracks this as AML.T0005 Replicate AI Model Behavior, a technique that ATLAS release 2026.10 renamed and rewrote (it was previously Create Proxy AI Model). The replica can be a surrogate used to develop evasion or jailbreak inputs offline, a functional copy that replaces paying for your service, or a student model that absorbs selected capabilities such as reasoning or coding. This guide explains the three sub-techniques, what each one leaves behind for defenders to see, which ATLAS mitigations apply and how to tune them, and how to respond when you suspect replication. It is written for AI platform owners, model developers, API security teams and SOC analysts. For the framework itself, see the MITRE ATLAS Guide.

Key takeaways

Replication is the step after collection. AML.T0005 covers training or adapting another model; collecting outputs is AML.T0135 Outputs from AI Models, and the API channel is AML.T0024 Exfiltration via AI Inference API. Defences work best on the collection side, because training happens on adversary infrastructure you never see.
Three routes, three defences. Replication from gathered artifacts is countered by limiting what you publish; replication from model outputs by access control, query limits and output degradation; adaptation of an existing model by limiting public detail about your model's behaviour.
It is realised at industrial scale. ATLAS links the technique to distillation campaigns reported by Anthropic, Google and a joint NSA, CISA and FBI advisory, with collection measured in millions of exchanges and, in Google's reporting, campaigns above 100 million prompts.
Surrogates power other attacks. Several ATLAS case studies use a replica of a security model (an email filter, a traffic detector, a malware classifier) to design inputs that evade the real one, so model replication is often the first sign of a coming evasion attempt.
Identity is the control point. Every harvested output was returned to an account or key. Verification at sign-up, linking of accounts, and per-key attribution decide whether a campaign is caught in days or never.

How the technique works

ATLAS describes AML.T0005 as adversaries replicating an AI model's behaviour or selected capabilities by training or adapting another model to approximate the target's responses, decision regions or other characteristics. Replication may cover the whole model or only the behaviours the adversary needs, and how close the copy must be depends on the goal. ATLAS places the technique in two tactics: Resource Development (AML.TA0003), when the result is a reusable capability, and AI Attack Adaptation (AML.TA0001), when the model is tailored for one target or operation. It applies to predictive, generative and agentic AI, and its maturity is rated realised.

Sub-technique	Source of the replica	Needs access to your model?	ATLAS maturity
AML.T0005.000 Replicate Behavior from Gathered AI Artifacts	Representative datasets, published architectures, training objectives, documented hyperparameters or pretrained components, obtained publicly (AML.T0002 Acquire Public AI Artifacts) or from victim environments (AML.T0035 AI Artifact Collection)	No. The copy can be built without ever querying the target	Demonstrated
AML.T0005.001 Replicate Behavior from Model Outputs	Labels, scores, probabilities, generated responses, reasoning explanations, evaluations, reward or preference signals, and tool use or agent trajectories collected from the target, used for supervised learning, distillation, fine-tuning or reinforcement learning	Yes, usually large volumes of queries	Realised
AML.T0005.002 Adapt Existing Model to Replicate Behavior	An existing model chosen because it already resembles the target, then fine-tuned or prompted and configured to match it more closely	Some, to measure similarity	Feasible

ATLAS notes that output-based replication may draw on several teacher models, filter or mix the collected material with other data, and reproduce selected capabilities rather than the target's full behaviour, architecture or output ontology. That matters for detection: a campaign aimed at one capability, such as code review or reasoning in one language, will look narrow and repetitive rather than broad.

Extraction through the API, and how it differs from privacy attacks such as membership inference, is covered in the MITRE ATLAS AML.T0024 Exfiltration via AI Inference API guide. The business and legal side of distillation is covered in the Model Extraction and Distillation Defence Guide. This page stays with the replication technique and what defenders can do about each route.

Real cases in ATLAS

ATLAS case study	Sub-technique	What happened	Lesson for defenders
AML.CS0056 Model Distillation Campaigns Targeting Anthropic Claude	.001	Anthropic reported in February 2026 about 24,000 fraudulent accounts generating over 16 million exchanges, attributed to three labs, targeting reasoning, agentic tool use and coding	Account farms defeat per-account limits; cluster accounts before scoring them
AML.CS0075 Model Distillation Campaigns Targeting Google AI Services	.001	Google reported a campaign of over 100,000 prompts seeking Gemini's full reasoning traces, and by September 2026 coordinated campaigns, some above 100 million prompts, spread across thousands of compromised and fraudulent accounts	Hidden reasoning is a prime target; protect it at the output layer and watch for prompts that try to elicit it
AML.CS0076 China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies	.001	NSA, CISA and FBI attributed campaigns to six companies, using fraudulent accounts, bulk premium subscriptions and gray-market proxies (transfer stations), with identifiers stripped from requests	Resellers and aggregators hide who is really calling; know which keys are used by intermediaries
AML.CS0007 GPT-2 Model Replication	.000	Researchers rebuilt the training dataset from public documentation and trained a functional replica using a similar public model's code	Detailed publication of data recipes and training settings is itself a replication input
AML.CS0008 email protection evasion (Proof Pudding)	.001	An email security product left model scores in message headers; researchers collected them, trained a copy, and used it to craft mail that scored as safe on the live system	Never expose raw model scores to the parties the model is judging
AML.CS0012 and AML.CS0014 (face identification, antimalware)	Parent	Red teams trained proxy models on open source or labelled data, then used them to develop evasion	A replica is often a staging step for AML.T0015 Evade AI Model

Two reporting threads are worth reading in full. Google Threat Intelligence Group's February 2026 report says its systems recognised the reasoning-trace campaign in real time and that its proactive defences can degrade student model performance. Anthropic describes classifiers and behavioural fingerprinting for distillation patterns, detection of chain-of-thought elicitation, and tools for spotting coordinated activity across many accounts. ATLAS summarises the joint advisory as also reporting that operators used automated quality checks to tell defensive countermeasures apart from ordinary service problems, so assume a well-resourced adversary will notice crude degradation.

Detection

You cannot observe the training step. You can observe artifact access, query collection and, later, models in the wild that behave suspiciously like yours. ATLAS mitigation AML.M0024 AI Telemetry Logging and Monitoring states that telemetry can help identify whether a proxy training dataset has been exfiltrated.

Signals by sub-technique

Route	Signal	Where to look
From outputs (.001)	Many accounts with identical prompt templates, synchronised timing and shared payment or device attributes	API gateway logs joined to account and billing data
From outputs (.001)	High volume concentrated in one capability area, or prompts that ask for full reasoning, grading rubrics or step-by-step explanations at scale	Prompt clustering and capability classifiers on request logs
From outputs (.001)	Traffic arriving through resellers, relays or aggregators, with prompt diversity behind a single key far wider than one application would produce	Per-key prompt diversity and source network analysis
From outputs (.001), predictive models	Systematic coverage of the input space and repeated requests for full confidence vectors	Inference logs on classifier and scoring endpoints
From artifacts (.000)	Bulk download of datasets, model cards, checkpoints or training configuration from internal registries or storage	Registry, object storage and repository access logs; see AML.T0035
Adaptation (.002)	A published or competing model whose outputs track yours on unusual inputs, such as your fingerprinting prompts or watermark checks	Periodic provenance testing of suspect models

Measuring it

Attribution coverage: share of inference traffic made with keys bound to a verified organisation and owner.
Time to cluster suspension: days from the first query of a confirmed replication cluster to suspension of all its accounts.
High-fidelity exposure: number of endpoints returning logits, log probabilities, full score vectors or unsummarised reasoning to unverified callers.
Recurrence rate: share of suspended clusters that return through new accounts within 30 days.
Artifact access anomalies: count of bulk reads of training data or checkpoints by identities outside the owning team.

Prevention: ATLAS mitigations mapped

ATLAS release 2026.10 links seven mitigations to AML.T0005 or its sub-techniques. The table shows what each one means in practice. Mitigation details and rollout across techniques are in the MITRE ATLAS Mitigations Guide.

ATLAS mitigation	Applies to	What to do	Trade-off
AML.M0000 Limit Public Release of Information	Parent, .000, .002	Review papers, blog posts, model cards and talks for training data recipes, hyperparameters and architecture detail that a competitor could reuse	Openness helps customers and research; decide per model, not by default
AML.M0001 Limit Model Artifact Release	Parent, .000	Keep checkpoints, adapters and curated datasets in access-controlled registries; publish only what has a business reason	Open-weight release strategies accept this risk deliberately
AML.M0002 Predictive AI Output Obfuscation	Parent, .001	Return only the outputs the application needs; withhold or round confidence scores, logits, class rankings and embeddings	Some customers need scores; reserve them for verified tiers
AML.M0004 Limit AI Service Query Volume and Rate	Parent, .001	Rate, burst and concurrency limits plus longer-term quotas per user, key, tenant and device; ATLAS says to monitor for limit evasion through distributed requests, account rotation or stolen credentials	Per-key limits alone fail against account farms
AML.M0019 Control Access to AI Models and Data in Production	Parent	Authenticate every endpoint, bind keys to verified organisations, restrict regions and tiers that need it	Sign-up friction; offer a fast path for real customers
AML.M0024 AI Telemetry Logging and Monitoring	.001	Log caller identity, prompt template cluster, token counts and output class with retention long enough to rebuild a slow campaign	Prompt logs are sensitive data; control access and retention
AML.M0040 Adaptive AI Response Degradation	Parent, .001	When replication is suspected, route requests to more constrained models, reduce precision or completeness, withhold reasoning detail and auxiliary outputs, or apply controlled perturbations	False positives degrade service for real users; tie degradation to confidence and severity

Protect reasoning traces: where a model produces internal reasoning, return a summary by default, as Google describes doing for Gemini, and treat prompts that try to force the full trace as a detection signal.
Know your intermediaries: list which customers resell or aggregate access, require them to pass end-user identifiers, and apply quotas to the intermediary as a whole.
Usage terms: prohibit training competing models on outputs. Google and Anthropic both cite terms of service as the basis for account action and, for Google, legal action.
Provenance and watermarking: OWASP LLM10 lists watermarking to detect unauthorised use of outputs, and Google reports techniques to identify Gemini-distilled models. Treat these as evidence after the fact. See the AI Model Provenance and Watermarking Guide.
Models on devices: a model shipped inside an app is an artifact the attacker already holds, so .000 needs no theft at all. See the On-Device AI Security Guide.

Choosing controls by exposure

Your situation	Main replication route	Put effort into
Public frontier or general-purpose LLM API	.001 at scale through account farms and resellers	Sign-up verification, account clustering, reasoning protection, adaptive degradation, intelligence sharing
Fine-tuned domain model sold as a service (finance, legal, code)	.001 focused on the narrow capability you sell, or .002 starting from a similar open model	Per-customer quotas, capability-level volume monitoring, output fidelity limits, contract terms
Security classifier (spam, fraud, malware, content moderation)	.001 using scores leaked to the judged party, then evasion	Remove scores from anything the subject can see, coarse verdicts only, ensemble and retrain cadence
Internal model used by many teams	.000 from registries and storage, or .001 with a stolen workload key	Registry access control, per-workload credentials, bulk read alerts
Model shipped on devices or as open weights	.000 directly from the artifact	Accept the exposure; keep security decisions server-side and do not rely on model secrecy

Small providers rarely have the data science capacity for behavioural fingerprinting. For them, verified sign-up, strict per-organisation quotas, no logits by default and an AI gateway that logs per-key usage deliver most of the value. See the AI Gateway and LLM Gateway Guide.

Where identity fits

Each of the campaigns above ran on identities: fraudulent accounts, compromised accounts, bulk-bought subscriptions and API keys passed through proxies. Our recommendations (NHI Mgmt Group):

One key per workload: separate keys for each customer application and internal consumer, so volume and prompt diversity can be attributed and one key revoked alone.
Verification recorded on the key: tie each key to an organisation and a human owner, and record the verification tier so limits and output fidelity can follow it.
Linked-account graph: join accounts on payment instrument, device, network and timing so that limits and suspensions apply to the cluster.
Stolen key watch: ATLAS and Google both mention compromised accounts; alert on keys whose usage pattern changes abruptly in volume, region or capability.

See the Rate Limiting and API Abuse Guide for limit design patterns.

Response

Scope the cluster: group accounts and keys by shared attributes, estimate total queries, capability areas covered and date range.
Preserve evidence: snapshot request logs, account records and billing data for the cluster before retention removes them.
Decide degrade or block: where confidence is moderate, apply AML.M0040 degradation and keep watching; where it is high, suspend the whole cluster and revoke its keys together so load cannot move to survivors.
Close the path: tighten verification on the sign-up route or account tier that was used, and require intermediaries to pass end-user identity.
Check artifact exposure: for .000, review who read datasets, checkpoints and configuration in the period, and rotate any credentials found in that path.
Share and record: share indicators with peers and, where relevant, authorities, as Anthropic reports doing, and log the incident against AML.T0005. See the AI Incident Reporting Guide.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0005, .000, .001, .002; tactics AML.TA0003 and AML.TA0001	Technique and sub-techniques
MITRE ATLAS related	AML.T0135 Outputs from AI Models, AML.T0024, AML.T0002, AML.T0035, AML.T0015, AML.T0048.004 AI Intellectual Property Theft	Collection steps before replication, and outcomes after it
MITRE ATLAS mitigations	AML.M0000, AML.M0001, AML.M0002, AML.M0004, AML.M0019, AML.M0024, AML.M0040	Mitigations ATLAS links to the technique
OWASP Top 10 for LLM Applications 2025	LLM10 Unbounded Consumption (model extraction via API, functional model replication)	Same risk from the application view
NIST SP 800-53 Rev. 5	AC-3, AC-6, SI-4, AU-12	Access enforcement, least privilege, monitoring, audit records
NIST CSF 2.0	PR.AA-05, PR.DS-10, DE.CM-09, DE.AE-02, RS.MI-01	Access policy, data in use, monitoring, analysis, containment

See the OWASP LLM Top 10 LLM10 Unbounded Consumption Guide for the OWASP view.

Common failure patterns

Scores visible to the judged party: a classifier verdict with a numeric score written into email headers, API responses or verbose logs lets the subject build a replica, as in AML.CS0008.
Limits per key only: quotas that never aggregate across linked accounts let thousands of small accounts stay under every threshold.
Reasoning returned in full: exposing raw chain-of-thought or step-by-step grading hands distillers the most valuable training signal.
Crude, constant degradation: blanket noise or truncation hurts real users and, as the joint advisory notes, can be spotted by adversary quality checks; tie degradation to detection confidence.
Publishing the recipe: detailed data curation steps and hyperparameters in a launch post can be enough for artifact-based replication, as AML.CS0007 shows.
Treating it as billing abuse: finance sees the volume, but nobody asks which capability was harvested or whether a security model is about to be evaded.

Practitioner checklist

Inventory every model endpoint with its authentication, output fidelity (scores, logits, reasoning) and the parties who can see outputs.
Remove model scores from anything the judged party can read, and return coarse verdicts by default.
Require verified sign-up for tiers with high quotas or high-fidelity outputs, and record the tier on each key.
Apply rate, burst, concurrency and quota limits per key, account, organisation and linked-account cluster.
Log caller identity, prompt template cluster and capability class, and review cluster analytics weekly.
Define AML.M0040 degradation actions with confidence thresholds, and test them for false positives on real customer traffic.
Review publications and model cards for replication-enabling detail before release.
Restrict registry and storage access to datasets and checkpoints, with alerts on bulk reads.
Write a replication response runbook: scope, preserve, degrade or block, close path, share, record.

AML.T0005 Replicate AI Model Behavior: How Model Replication Works and How to Defend