Most attacks on AI systems start with nothing more than the access a normal customer has: an API key and an inference endpoint that answers every query. MITRE ATLAS tracks this as AML.T0040 AI Model Inference API Access, in the AI Model Access tactic (AML.TA0000), and rates it as realised across predictive, generative and agentic AI. ATLAS describes the inference API as a source of information about the model, a place to stage and test attacks, and a way to feed data into the target system for impact. This guide covers the forms the technique takes, how to control and monitor inference access whether you serve models or consume them, detection signals and a rollout plan. It is for platform, ML and security teams running or relying on model endpoints, and goes deeper than the MITRE ATLAS Guide.
Key takeaways
- Legitimate access is the attack surface. AML.T0040 needs no exploit; queries look like normal use, so the defence is in authentication, quotas and analysis of query patterns.
- It is a gateway technique. ATLAS links it to discovery (AML.T0013, AML.T0014), staging (AML.T0042, AML.T0043) and impact (AML.T0015, AML.T0031).
- Shared models share weaknesses. ATLAS notes that many applications use the same foundation model through an API, so a jailbreak found against the public model can be aimed at every application built on it.
- Stolen keys turn it into abuse. In AML.CS0057 Storm-2139 used customer credentials scraped from public sources to reach Azure OpenAI Service; key hygiene is part of this technique's defence.
- ATLAS maps three mitigations. AML.M0019 Control Access to AI Models and Data in Production, AML.M0024 AI Telemetry Logging and Monitoring and AML.M0039 AI Honeypots.
How the technique works
AML.T0040 dates from the first ATLAS release (created May 2021, last modified May 2026) and has no sub-techniques. The adversary uses the same request path as a legitimate client, either through their own account, through an account they have taken over, or through a public endpoint that needs no authentication. What they do with that access falls into three groups, as ATLAS describes them.
| Use of inference access | Linked ATLAS techniques | What the adversary learns or achieves |
|---|---|---|
| Information gathering | AML.T0013 Discover AI Model Ontology, AML.T0014 Discover AI Model Family | Output classes, model type and family, inferred from responses |
| Staging the attack | AML.T0042 Verify Attack, AML.T0043 Craft Adversarial Data | Inputs refined and tested against the live model until they work |
| Introducing data for impact | AML.T0015 Evade AI Model, AML.T0031 Erode AI Model Integrity | Evasion of the model's decision, or degraded integrity over time |
Two further consequences follow from the same access. Repeated queries can be used to copy a model's behaviour (ATLAS AML.T0005 Replicate AI Model Behavior) or to pull out information through responses, which is covered in MITRE ATLAS AML.T0024 Exfiltration via AI Inference API. And when the access is paid for by someone else, it becomes cost and abuse, as in LLMjacking.
Real cases in ATLAS
ATLAS links AML.T0040 to more case studies than most techniques. They fall into four settings.
| Setting | ATLAS case study | What inference access gave the adversary |
|---|---|---|
| Red team against a target model | AML.CS0010 Microsoft Azure Service Disruption; AML.CS0011 Microsoft Edge AI Evasion; AML.CS0012 Face Identification System Evasion via Physical Countermeasures | An exposed or public API to query the target, analyse responses and refine evasion inputs |
| Research using a public model API | AML.CS0022 ChatGPT Package Hallucination; AML.CS0024 Morris II Worm: RAG-Based Attack | The same model that powers target applications, used to develop attacks against those applications |
| Abuse of stolen access | AML.CS0057 Storm-2139 Azure OpenAI Guardrail Bypass | Customer credentials scraped from public sources gave access to Azure OpenAI Service; the group built tooling to bypass safeguards and resold access. Microsoft took civil legal action from December 2024 |
| Commercial model as an attack engine | AML.CS0069 GTG-1002 Claude Code Espionage Campaign; AML.CS0070 Threat Actor Uses a DeepSeek-Powered Hermes Agent in Langflow and n8n Exploitation Attempts | Model access used to plan and run intrusion steps against third parties |
In GTG-1002, Anthropic reported in November 2025 that a group it assessed as Chinese state-sponsored used Claude Code within an attack framework against about 30 organisations, posing as a security firm and splitting work into small tasks; account bans and new classifiers ended it. See the Anthropic GTG-1002 Campaign. In AML.CS0070, Unit 42 reported in July 2026 that an actor's Hermes agent called the DeepSeek API directly to choose targets and generate commands, and advised defenders to watch for outbound connections to LLM provider endpoints from servers with no reason to use them.
Two defensive positions
Most organisations sit on both sides of this technique, and the controls differ.
| Position | Main risk from AML.T0040 | Priority controls |
|---|---|---|
| You serve a model (internal endpoint, product feature, customer API) | Discovery, attack staging, extraction and cost abuse by authenticated or anonymous callers | Authentication on every endpoint, per-identity quotas, output minimisation, query logging and analysis |
| You build on a third-party model | Attacks developed against the public model and replayed against your application; your provider keys stolen and abused | Application-level guardrails you control, key management and spend limits, egress control for model traffic |
| You run servers and agents | Malicious agents on compromised hosts calling model APIs | Allowlist which hosts may call which LLM endpoints; alert on new model API destinations |
Prevention: the ATLAS mitigations
| ATLAS mitigation | What it means for this technique |
|---|---|
| AML.M0019 Control Access to AI Models and Data in Production | Require callers to verify identity before reaching a production model, require authentication on API endpoints and monitor queries for usage policy compliance. ATLAS notes unrestricted API access lets adversaries gather information, stage attacks and introduce malicious data |
| AML.M0024 AI Telemetry Logging and Monitoring | Log API usage of the model so it can be audited |
| AML.M0039 AI Honeypots | Decoy model endpoints capture which endpoints adversaries target, the models they want, the parameters they use and the payloads they submit |
Controls in practice
- Authenticate every endpoint: no anonymous inference on internal or staging models; tie each request to a user, workload or tenant identity rather than a shared key.
- Per-identity quotas: rate limits and token or request budgets per key, per user and per tenant, with alerts before hard stops. OWASP LLM10:2025 Unbounded Consumption lists rate limiting, timeouts and throttling. See AI Agent Rate Limits.
- Minimise outputs: return labels rather than full probability vectors where the use case allows. OWASP LLM10:2025 recommends limiting exposure of logits and logprobs, which reduces both discovery and extraction value.
- Central gateway: route model calls through a gateway that enforces identity, quotas, logging and content policy in one place. See the AI Gateway and LLM Gateway Guide.
- Own your guardrails: if you build on a shared foundation model, assume its public jailbreaks will be tried on you; add input and output controls you can update without waiting for the provider.
- Egress allowlist: only approved hosts and workloads may reach external LLM APIs; others are blocked and alerted.
Where identity fits
Inference access is granted to an identity, usually an API key. Storm-2139 used exposed customer credentials; ATLAS tracks the same entry through AML.T0012 Valid Accounts and AML.T0055 Unsecured Credentials. Treat model provider keys as non-human identities: one key per application and environment, an owner, spend limits, rotation and scanning of code and CI for leaks. Prefer workload identity federation or short-lived tokens where the provider supports them. See the LLMjacking Guide and How to set spend limits on LLM API keys.
Detection
| Signal | Possible meaning | Data source |
|---|---|---|
| High query volume with systematically varied inputs | Ontology discovery, attack crafting or extraction | Gateway or endpoint request logs |
| Many near-duplicate inputs with small perturbations | Adversarial example search (AML.T0043) or verification (AML.T0042) | Input similarity analysis on logs |
| Requests at machine speed from a user identity | Automation on a human account, or a stolen key | Per-identity rate metrics |
| Key used from new networks, regions or client types, or spend spike | Stolen provider or customer key | Provider usage dashboards, billing alerts |
| Repeated guardrail or content-filter triggers from one identity | Jailbreak development | Content safety logs |
| New outbound destination to an LLM API from a server | Unapproved or malicious agent on the host (AML.CS0070) | Proxy, DNS and firewall logs |
| Any request to a decoy endpoint | Active reconnaissance (AML.M0039) | Honeypot logs |
Measuring it
- Authenticated coverage: share of model endpoints that reject unauthenticated requests; target 100 percent.
- Attribution: share of inference requests attributable to a named identity rather than a shared key.
- Quota coverage: share of keys with rate and spend limits set.
- Detection time: time from first anomalous query burst or spend spike to triage.
- Egress control: share of hosts covered by an LLM API egress allowlist.
Implementation steps
- Inventory: list every model endpoint you serve (including staging and internal) and every external model API your applications call, with the keys used.
- Close anonymous access: require authentication everywhere; for public products, require an account and apply stricter quotas to new or free accounts.
- Log before limiting: collect per-identity request logs through a gateway for a few weeks to learn normal volumes and patterns.
- Set quotas: apply rate and spend limits per identity in report-only mode, review false positives, then enforce. Roll back by raising the limit for the affected identity, not by removing it.
- Reduce outputs: remove confidence scores and logprobs from responses that do not need them.
- Harden keys: split shared keys, move them to a secrets manager, set spend alerts and scan repositories and CI.
- Control egress: allowlist model API destinations per workload and alert on new ones.
- Add decoys: where you have mature monitoring, deploy a decoy endpoint and treat any hit as an alert.
A small team calling one provider can cover most of this with per-application keys, provider spend limits and an egress rule. Organisations serving models to customers need the gateway, per-tenant quotas and query analytics.
Common failure patterns
- Unauthenticated internal endpoints: inference servers reachable inside the network with no authentication, on the assumption that only trusted services call them. See the vLLM, Triton and NVIDIA NIM Inference Server Security Guide.
- One key for everything: a single provider key shared across applications, so abuse cannot be traced or contained.
- Full scores returned by default: probability vectors exposed when the product only needs a label.
- Relying on the provider's guardrails alone: the same guardrails are public to every attacker who can test them.
- Billing as the only alarm: abuse found at month end instead of from per-identity monitoring.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1078.004 Cloud Accounts | Use of valid or stolen cloud service credentials to reach model services |
| OWASP Top 10 for LLM Applications 2025 | LLM10:2025 Unbounded Consumption | Rate limiting, logit exposure, model extraction via API and denial of wallet |
| NIST SP 800-53 Rev 5 | AC-2 Account Management; IA-5 Authenticator Management; AU-12 Audit Record Generation; SI-4 System Monitoring; SC-7 Boundary Protection | Identity per caller, key management, request logging, monitoring and egress control |
| NIST CSF 2.0 | PR.AA-05; PR.PS-04; DE.CM-09 | Least privilege, logging and monitoring of runtime environments |
| ISO/IEC 27001:2022 Annex A | 5.15 Access control; 8.5 Secure authentication; 8.16 Monitoring activities | Policy-level access and monitoring for model endpoints |
Practitioner checklist
- Every model endpoint, including staging and internal, requires authentication.
- Every request is attributable to a named user, workload or tenant.
- Rate and spend limits are set per identity, with alerts before hard limits.
- Responses expose only the outputs the use case needs.
- Model calls go through a gateway that logs and enforces policy.
- Provider keys are per application and environment, stored in a secrets manager and scanned for in code.
- Only approved workloads may reach external LLM APIs.
- Query logs are analysed for perturbation patterns, machine-speed use and repeated filter triggers.
Standards and references
- MITRE ATLAS: AML.T0040 AI Model Inference API Access
- MITRE ATLAS: AML.M0019 Control Access to AI Models and Data in Production
- MITRE ATLAS: AML.CS0057 Storm-2139 Azure OpenAI Guardrail Bypass
- OWASP: LLM10:2025 Unbounded Consumption
- Microsoft: Disrupting a global cybercrime network abusing generative AI
- Anthropic: Disrupting the first reported AI-orchestrated cyber espionage campaign
- Palo Alto Networks Unit 42: Autonomous AI cyber attack campaign report
Related NHI Mgmt Group resources: MITRE ATLAS Guide, Model Extraction and Distillation Defence Guide, LLMjacking Guide, AI Gateway and LLM Gateway Guide.