When requests reach an AI service with their client, session and organisation identifiers stripped or replaced, the provider loses the signals it needs to link coordinated activity back to one operator. MITRE ATLAS added this as AML.T0141 AI Service Request Metadata Sanitization in release 2026.10 (28 October 2026), under the Defense Evasion tactic (AML.TA0007), with maturity rated Realized. ATLAS describes adversaries removing or replacing identifying information in request metadata, often automatically in clients, relays, aggregators or central routing infrastructure, to impede attribution. This page is for two audiences: teams that run AI APIs or model platforms and need to detect sanitised traffic, and enterprise teams running AI gateways who must keep their own attribution intact while making sure staff are not routing work through gray-market relays. The framework overview is in the MITRE ATLAS Guide.
Key takeaways
- It is an evasion layer, not an attack on its own. Sanitisation hides who is behind traffic that serves another goal, such as large-scale output collection for distillation.
- The signal is what disappears. The joint NSA, CISA and FBI reporting cited by ATLAS points to previously consistent metadata vanishing and generic or randomised values replacing organisational markers.
- Relays do it by design. ATLAS links the open source Claude Relay Service (AML.S0032) to this technique because it removes client IP, forwarding and CDN headers, or forwards only an allowlist.
- Attribution must not rely on client-supplied fields. Anything the client sends can be removed or forged; durable attribution comes from account, payment, key and behavioural evidence held server-side.
- No ATLAS mitigation is mapped yet. As of release 2026.10, ATLAS lists no mitigations for AML.T0141, so defenders build controls from identity, logging and abuse-detection practice.
How the technique works
Every request to an AI service carries metadata beyond the prompt. ATLAS lists the kinds of fields an adversary may target and the two ways they are changed: removal, or replacement with normalised, randomised or generated values.
| Metadata type (per ATLAS) | Typical location | What the provider loses when it is sanitised |
|---|---|---|
| Client or device identifiers | Headers, SDK telemetry fields | Ability to link many accounts to one machine or fleet |
| Session identifiers | Headers, request body | Continuity between requests that belong to one workflow |
| Account identifiers | Request body fields, user tags | End-user attribution behind a shared API key |
| Client software identifiers | User-Agent and SDK version headers | Tooling fingerprint shared across a campaign |
| Forwarding headers | X-Forwarded-For, CDN client-IP headers | Original source address behind a proxy |
| Attribution markers in request bodies | Organisation or project tags, metadata objects | Organisational origin of the request |
The Claude Relay Service source code referenced by ATLAS shows both patterns. Its OpenAI path removes a fixed list of headers, including x-real-ip, x-forwarded-for, cf-connecting-ip, cf-ipcountry and true-client-ip. Its Claude path works as an allowlist, passing only named headers such as anthropic-version, anthropic-beta, user-agent and content-type, so anything else the client sent never reaches the upstream service. Header filtering of this kind is common in legitimate proxies too; what makes it AML.T0141 is the intent to defeat correlation.
The technique usually sits beside two neighbours in ATLAS: AML.T0008.005 AI Service Proxies (the infrastructure) and AML.T0140 Centralized AI Service Request Routing (spreading traffic across providers, aggregators and account pools). AML.T0138 Indicator Removal covers deleting evidence after the fact. Each has its own ATLAS entry.
Real case: industrial-scale distillation (AML.CS0076)
ATLAS case study AML.CS0076 records the joint NSA, CISA and FBI advisory AA26-251A, released on 8 September 2026, which attributed industrial-scale distillation campaigns to six China-based AI companies. According to ATLAS, the companies collected outputs from U.S. models over millions of exchanges, accessed services through fraudulent accounts, bulk premium subscriptions and gray-market proxies called "transfer stations", and routed requests through centralised infrastructure across APIs, cloud services, aggregators and account pools. Step S05 of the case study maps to AML.T0141: the operators automatically removed organisational identifiers from requests to obscure their origin and hinder attribution.
Secondary summaries of the advisory from the Cloud Security Alliance describe the behavioural indicators providers were asked to watch: usage far beyond what a billing tier would normally support, new accounts reaching maximum throughput at once, and round-the-clock query patterns that do not match human pacing. Those indicators matter here because they survive sanitisation; header fields do not. For the provider-side defence against the collection itself, see the Model Extraction and Distillation Defence Guide.
Detection
Detection works on change and inconsistency, because a sanitised field is often simply absent. The table below lists signals a provider or a gateway operator can build from its own logs.
| Signal | Why it points to sanitisation | Data needed |
|---|---|---|
| Field present in an account's history, then absent on every request from a date onward | ATLAS cites the disappearance of previously consistent metadata as an indicator | Per-account baseline of header and body-field presence |
| High-cardinality random values in fields that are normally stable (session, device, user tag) | Generated values replace real identifiers | Distinct-value counts per key per day |
| Identical User-Agent and SDK headers across many unrelated accounts | Normalised values erase per-client fingerprints | Header hash grouped across accounts |
| Forwarding headers never present while source IPs belong to hosting or proxy ranges | A relay stripped the chain of origin | IP reputation and ASN enrichment |
| Header set that exactly matches a known relay allowlist | Allowlist filtering leaves a recognisable shape | Header-name set fingerprint |
| Volume, timing and prompt-domain concentration out of line with the plan tier | Behaviour survives when identifiers do not | Usage, billing and content-category telemetry |
Correlate on what the adversary cannot strip: payment instruments, account creation details, API key issuance, request timing, prompt templates and topic concentration. Group accounts by these and treat sanitised metadata as a weight in the score, not a verdict.
Expect false positives: privacy-preserving enterprise gateways, corporate egress proxies and SDK upgrades all change header shape legitimately. Pair every rule with an allow path for verified enterprise customers.
Prevention and hardening
For AI service providers
- Anchor identity server-side: bind each request to the authenticated account and API key, and record that binding in the log entry, so attribution never depends on headers. See the AML.T0021 Establish Accounts page for account-creation controls.
- Raise the cost of account pools: verification proportionate to tier and volume, and review of bulk subscription purchases, which the advisory summaries highlight.
- Tie rate limits to behaviour: risk-scored throttling rather than flat per-key limits, as described in the Rate Limiting and API Abuse Guide.
- Share indicators: proxy ranges, relay fingerprints and transfer-station domains are most useful when exchanged between providers.
For enterprises running AI gateways
- Keep your own attribution: if your gateway strips user or device headers before sending traffic upstream for privacy, log the mapping internally first. An investigation should be able to tie any upstream request ID to a person, workload or agent identity. See the AI Gateway and LLM Gateway Guide.
- Use approved paths only: block or alert on traffic from corporate devices to unapproved AI relays and aggregators, and route AI API access through the sanctioned gateway with issued keys.
- Treat keys as identities: provider API keys used through a relay become shared credentials with no owner. Inventory and rotate them, as covered in the OpenAI API Keys Security Guide.
How to implement
- Inventory metadata: list every header and body field your service or gateway logs per request, and mark which are client-supplied and which are server-derived.
- Baseline per account: record field presence and distinct-value counts per account over 30 days.
- Deploy rules in alert-only mode: start with the disappearance and uniform-header rules; review a sample of hits weekly with the abuse or trust-and-safety team.
- Add behavioural scoring: combine metadata signals with volume, timing and domain concentration; tune until false positives on verified enterprise customers are rare.
- Introduce graded responses: step-up verification, lower limits, then suspension, with a documented appeal route and legal review of any response degradation.
- Roll back safely: keep each rule behind a flag so it can return to alert-only if a customer integration breaks.
Metrics
- Share of requests whose upstream log entry can be tied to a named account and key (target: all).
- Number of account clusters linked by server-side evidence despite sanitised metadata, per month.
- Median time from first sanitisation signal to analyst decision.
- False-positive rate of sanitisation rules on verified enterprise customers.
- For enterprises: share of AI API traffic leaving through the sanctioned gateway.
Common failure patterns
- Trusting forwarding headers for attribution: X-Forwarded-For is client-controlled and is the first thing a relay removes.
- Logging only what the client sent: without the server-side account and key binding, a sanitised request is anonymous in the logs.
- Static rate limits as the only control: distributing traffic across account pools keeps every key under the limit.
- Privacy gateways without an internal map: enterprises strip user identity upstream and then cannot answer which user or agent sent a request during an incident.
- Treating any missing header as hostile: blanket blocking breaks legitimate proxies and teaches operators to fabricate plausible values instead of removing them.
Framework mapping
| Framework | Item | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0141, tactic AML.TA0007 Defense Evasion | The technique itself |
| MITRE ATLAS | AML.T0008.005 AI Service Proxies, AML.T0140 Centralized AI Service Request Routing | Infrastructure that commonly performs the sanitisation |
| MITRE ATT&CK | T1090 Proxy | Enterprise analogue for routing through intermediaries; see the T1090 Proxy Defensive Guide |
| NIST SP 800-53 Rev. 5 | AU-3 Content of Audit Records, AU-10 Non-repudiation, IA-4 Identifier Management, SI-4 System Monitoring | Server-side attribution in logs and monitoring for anomalous use |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Monitoring network services and analysing adverse events |
Practitioner checklist
- Log the authenticated account and key with every request, server-side.
- Classify each logged field as client-supplied or server-derived.
- Baseline metadata presence per account and alert on sudden disappearance.
- Fingerprint header-name sets and compare against known relay patterns.
- Score accounts on behaviour (volume, timing, topic concentration), not headers alone.
- Enterprises: keep an internal user-to-request map before any upstream header stripping.
- Enterprises: alert on corporate traffic to unapproved AI relays and aggregators.
- Run new rules in alert-only mode with a rollback flag.
Standards and references
- MITRE ATLAS: AI Service Request Metadata Sanitization (AML.T0141)
- MITRE ATLAS: China-Based AI Companies Conducting Industrial-Scale Distillation Campaigns (AML.CS0076)
- MITRE ATLAS: Claude Relay Service (AML.S0032)
- GitHub: Claude Relay Service header filtering implementation
- Cloud Security Alliance: Research note on the CISA China AI distillation advisory
- Nextgov: Intelligence agencies warn of China's large-scale AI model distillation efforts
- MITRE ATT&CK: Proxy (T1090)
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: MITRE ATLAS Guide, Model Extraction and Distillation Defence Guide, AI Gateway and LLM Gateway Guide, AML.T0021 Establish Accounts, Rate Limiting and API Abuse Guide.