ATLAS AML.T0042 Verify Attack: Defender Guide

Before an adversary uses an adversarial input, a poisoned model or a prompt injection against you for real, it usually checks that the attack works, and that check is one of the few moments you can see it coming. MITRE ATLAS tracks this step as AML.T0042 Verify Attack, in the AI Attack Adaptation tactic (AML.TA0001), with maturity rated Realized across predictive, generative and agentic AI. ATLAS describes verification through an inference API or through an offline copy of the target model, and notes that it can be hard to detect because the adversary may need only a few queries, or none at all against your systems. This guide is for ML platform owners, AI security engineers and detection teams: how verification happens, what the ATLAS case studies show, which mitigations ATLAS maps, and how to make rehearsal expensive and visible. For the framework itself, see the MITRE ATLAS Guide.

Key takeaways

Verification is the dress rehearsal. The adversary tests a crafted input or modified model against the target, or a copy of it, so it can launch later with confidence and at a time of its choosing.
Offline copies remove your visibility. If the model ships to edge devices or leaks, the adversary can verify without ever touching your endpoints, and one verified attack can then work against every device running that model.
ATLAS maps five mitigations. AML.M0002 Predictive AI Output Obfuscation, AML.M0004 Limit AI Service Query Volume and Rate, AML.M0005 Control Access to AI Models and Data at Rest, AML.M0019 Control Access to AI Models and Data in Production and AML.M0040 Adaptive AI Response Degradation.
Look for small, odd query sets. Verification traffic is often low volume but unusual: near-duplicate inputs, probes with harmless markers, malformed requests that confirm access, and queries from fresh identities.
Your own red team does the same thing. Verification steps in ATLAS case studies come largely from authorised research, so the same telemetry that catches an adversary should catch your testers, which is a cheap way to prove detection works.

How the technique works

ATLAS places Verify Attack in AI Attack Adaptation, the tactic in which an adversary turns general capabilities, target knowledge and observations into attack-ready outputs for a specific target. Verification is the quality gate at the end of that work. The adversary already has something to test: an adversarial example from AML.T0043 Craft Adversarial Data, a backdoored or modified model, a prompt injection, or a poisoned retrieval document. It now asks one question: does this work against the real target?

ATLAS gives four points about the technique:

Two routes: the attack is checked either through an inference API (online verification) or against an offline copy of the target model.
Timing control: once verified, the attack can be carried out later, when the adversary chooses.
Scale: an attack verified once can be used against many edge devices running copies of the same model.
Digital first, physical later: an attack may be verified digitally and then deployed through AML.T0041 Physical Environment Access, for example a printed pattern aimed at a camera-based model. See AML.T0041 Physical Environment Access.

Verification is distinct from developing the attack. Developing it may involve thousands of queries against a proxy model; verifying it can be a handful of queries against the production system, which is why ATLAS warns that it can be hard to spot.

Verification routes and what defenders can see

Route	What the adversary needs	What you can observe	Main ATLAS mitigation
Production inference API	An account, API key or public endpoint (AML.T0040 AI Model Inference API Access)	Query logs, unusual input patterns, rejected requests, new identities	AML.M0019, AML.M0004, AML.M0040
Product that embeds the model	Access to the application, such as a chatbot, filter or detector	Application logs, verdicts per account, test-like inputs	AML.M0019, AML.M0004
Offline copy of the production model	Model files from an edge device, app package, leak or registry (AML.T0044 Full AI Model Access)	Little or nothing at verification time; only the earlier theft or extraction	AML.M0005, plus model distribution choices (AML.M0017)
Detailed model outputs	Scores, logits or rankings returned by a predictive endpoint	Clients that consistently request maximum output detail	AML.M0002
Agent or LLM application	A way to place content the agent reads, then observe the result	Harmless marker strings, tool calls that echo test content	AML.M0019, monitoring of agent actions

What the ATLAS case studies show

ATLAS links Verify Attack to several case studies. Most are authorised research or red team work, which makes them useful as patterns for both detection and testing.

Case study	How the attack was verified	Defensive lesson
AML.CS0000 Evasion of Deep Learning Detector for Malware C&C Traffic	Researchers queried the model with adversarial examples and adjusted them until it was evaded	Iterative near-duplicate queries are a visible signal when the model is reachable
AML.CS0001 Botnet DGA Detection Evasion	Results showed detection of 16 DGA families fell below 25% after one inserted string	Small input changes can be validated with very few tests
AML.CS0010 Microsoft Azure Service Disruption	Red team submitted adversarial examples to the API to verify efficacy on the production system	Offline work ends with an online check against production
AML.CS0013 Backdoor Attack on Deep Learning Models in Mobile Apps	Researchers confirmed the app still worked with the malicious model and the trigger detector fired	On-device models can be verified entirely outside your telemetry
AML.CS0014 Confusing Antimalware Neural Networks	Adversarial files were tested against the target antimalware product	Security products are themselves a verification oracle
AML.CS0016 Achieving Code Execution in MathGPT via Prompt Injection	Harmless test prompts confirmed the injection class worked before anything harmful was attempted	Benign marker payloads often precede the real one
AML.CS0019 PoisonGPT	The modified model was benchmarked against the original and differed by about 0.1% in accuracy	Benchmarks alone will not reveal a tampered model
AML.CS0024 Morris II Worm: RAG-Based Attack	Crafted prompts were checked against public GenAI APIs for replication and data leakage	Adversaries may verify on public models before targeting yours
AML.CS0076 Industrial-scale distillation campaigns (NSA, CISA, FBI)	Automated quality-assurance pipelines checked acquired responses and tried to tell defensive degradation from ordinary service problems	Adversaries verify whether your defences are degrading their results

ATLAS also records the de3u tool (AML.S0020) as implementing this technique: it reported whether Azure OpenAI Service had rejected an image prompt for policy reasons, and Microsoft said that feedback helped users find ways around content protections. The wider abuse campaign is covered in Microsoft's write-up on Storm-2139.

Prevention: make verification costly and unreliable

Control who can query, and how much

Authenticate every endpoint (AML.M0019): no anonymous inference access to production models. Tie each query to a user, API key, tenant or workload identity so that limits and investigations have a subject.
Layered limits (AML.M0004): ATLAS describes short-term rate, burst and concurrency limits together with longer-term quotas, applied per user, key, tenant or device. Limits matter less against a single verification query than against the refine-and-retry loop that usually precedes it.
Account friction for free tiers: verification often uses throwaway accounts. Sign-up checks, payment verification or approval for higher tiers raise the cost of starting over.

Return less feedback

Output obfuscation (AML.M0002): for predictive endpoints, return only what the application needs. Withhold or round confidence scores, logits, class rankings and embeddings where the use case allows.
Uninformative rejections: the de3u case shows that a clear "rejected for policy" signal is itself an oracle. Keep refusal and error messages consistent, and avoid returning which rule fired.
Adaptive degradation (AML.M0040): when activity looks like extraction or attack testing, modify responses to limit their value to the adversary while keeping legitimate use working. CS0076 shows capable adversaries test for this, so degrade selectively and keep evidence.

Protect the offline route

Access to models at rest (AML.M0005): restrict registries, artifact stores and training data to approved users and workloads. A stolen copy turns verification into an offline, invisible step.
Distribution choices (AML.M0017): serving a model in the cloud rather than on edge devices reduces how much access an adversary can get. Where edge deployment is necessary, assume the model will be extracted and design the system so one verified bypass does not defeat every control.

Deeper coverage of extraction controls is in the Model Extraction and Distillation Defence Guide.

Detection and measurement

Verification traffic is small, so detection depends on context: who is asking, what they send and what happened just before.

Signal	Why it can indicate verification	Where to log it
Near-duplicate inputs with small perturbations	Matches the refine-and-check loop seen in CS0000 and CS0014	Inference request logs with input hashes or embeddings
Harmless marker payloads in prompts or documents	Benign tests, such as printing a fixed string, preceded the real attack in CS0016	Prompt and tool-call logs for LLM apps and agents
Malformed or zero-output requests that confirm access	In the LLMjacking case Sysdig observed InvokeModel calls with an invalid parameter that returned ValidationException, confirming access without running a prompt	Cloud audit logs (for example AWS CloudTrail) and provider API logs
Queries probing logging configuration	Sysdig also saw GetModelInvocationLoggingConfiguration calls before abuse	Cloud control plane logs
Bursts of policy rejections from one identity	Repeated refusals suggest someone mapping the filter	Content safety and moderation logs
New identities requesting maximum output detail	High-fidelity outputs help optimise and confirm attacks	API gateway logs

CloudTrail records API calls but not prompts or responses, so turn on model invocation logging where the platform offers it if you need content-level evidence. The LLMjacking case shows how quiet access checks preceded large-scale abuse of stolen keys.

Metrics that show the controls are working:

Percentage of production inference endpoints that require authenticated identity (target 100%).
Percentage of predictive endpoints returning only the output fields the application needs.
Median time from a near-duplicate probing pattern to an alert, measured with red team traffic.
Number of identities hitting policy rejection thresholds per week, and the share investigated.
Percentage of model artifacts in registries with access limited to named roles and workloads.

Response when verification is suspected

Preserve evidence: keep the query logs, inputs, outputs and identity details for the suspect sessions before any rotation or blocking.
Identify what was tested: classify the inputs (evasion, injection, extraction, poisoning check) so you know which later technique to expect, such as AML.T0015 Evade AI Model or AML.T0051 LLM Prompt Injection.
Contain the identity: throttle, step up or suspend the account or key; revoke keys that may be stolen.
Harden the specific weakness: retrain or add input checks for the confirmed adversarial pattern, fix the injection path, or reduce output detail.
Check for offline access: if verification traffic stops abruptly or never appears, consider whether a model copy has leaked, and review registry and artifact access.
Feed the red team: replay the observed pattern in testing so detection and the fix are both proven.

Framework mapping

Framework	Item	Relevance
MITRE ATLAS	AML.T0042 Verify Attack (tactic AML.TA0001 AI Attack Adaptation)	The technique itself
MITRE ATLAS	AML.M0002, AML.M0004, AML.M0005, AML.M0019, AML.M0040	Mitigations ATLAS maps to the technique
NIST SP 800-53 Rev. 5	AC-3, AC-6, SC-28	Access enforcement and least privilege for endpoints and models at rest
NIST SP 800-53 Rev. 5	SI-4, AU-6	Monitoring and review of inference and audit logs
NIST SP 800-53 Rev. 5	CA-8	Testing that replays verification patterns
NIST CSF 2.0	PR.AA-05, PR.PS-04, DE.CM-09, DE.AE-02	Access policy, log generation, monitoring and analysis
NIST AI 100-2 E2025	Adversarial ML taxonomy	Terminology for evasion, poisoning and extraction attacks being verified

The full mitigation set is explained in the MITRE ATLAS Mitigations Guide.

Common failure patterns

Anonymous or shared keys on inference endpoints: without a per-identity subject there is nothing to limit or investigate.
Verbose outputs by default: full probability vectors and detailed refusal reasons give the adversary a precise oracle.
Edge models treated as secret: models in apps and devices are assumed safe, so a verified bypass works across the whole fleet.
Volume-only alerting: rate alerts miss the few targeted queries that verification needs.
Benchmark-only acceptance of third-party models: PoisonGPT showed a tampered model can match the original on a standard benchmark.

Practitioner checklist

Require authenticated identity on every production inference endpoint and log the identity with every request.
Apply rate, burst, concurrency and quota limits per identity, with higher tiers approved.
Reduce predictive outputs to the fields the application needs; keep refusal messages uniform.
Restrict model registries, artifact stores and training data to named roles and workloads.
Decide deliberately which models may run on edge devices and plan for their extraction.
Log inputs, outputs and tool calls with hashes so near-duplicate probing can be found.
Alert on malformed access checks, logging-configuration queries and policy rejection bursts.
Run red team exercises that include a verification step and confirm it is detected.

AML.T0042 Verify Attack: Detect and Deny Adversaries Their Attack Rehearsals