ATLAS AI Model Access Tactic: Controlling Who and What Can Query Your Models

Almost every attack on an AI system needs some way to reach the model, and the AI Model Access tactic (AML.TA0000) in MITRE ATLAS is where defenders decide how much of that reach an adversary gets. ATLAS describes the tactic as the adversary "attempting to gain some level of access to an AI model", ranging from full knowledge of the model's internals to access to the physical environment where its input data is collected. The access may come through the system that hosts the model, a public API, or indirectly through a product or service that uses AI. This hub covers the four techniques in the tactic in ATLAS 2026.10, ranks them for defenders, shows how documented case studies chain them, and sets out the controls and detections that apply across the tactic. It is written for AI platform owners, ML engineers, application security teams and SOC analysts. Each technique has its own deeper page, linked below.

Key takeaways

• Access level decides attack options. Query access through an API, indirect access through a product, white box access to weights and physical access to sensors each unlock different later techniques, so the tactic is really a question of which level you expose and to whom.
• Indirect access through products dominates the case studies. AI-Enabled Product or Service (AML.T0047) appears in 15 of the 27 ATLAS case studies that include a step under this tactic; inference API access (AML.T0040) appears in 8.
• Stolen keys turn model access into an identity problem. Storm-2139 used exposed customer credentials to reach Azure OpenAI Service, and the AIKatz research extracted desktop app tokens to talk to the LLM backend as the victim.
• White box access is usually given away, not broken in. The Full AI Model Access (AML.T0044) cases involve models shipped inside mobile apps and private models uploaded to a public hub organisation the researcher controlled.
• Telemetry is the shared control. AI Telemetry Logging and Monitoring (AML.M0024) is the only mitigation ATLAS maps to more than one technique in the tactic.

What AI Model Access means in practice

In ATT&CK terms, AI Model Access is closest to a mix of Initial Access and Resource Development, but it is specific to the model rather than the network. An adversary who can query a model can learn its ontology and family, test adversarial inputs, extract outputs at scale for replication, run up costs or feed poisoned data back in. An adversary with the weights can do all of that offline, where nobody sees the attempts. ATLAS states that adversaries may use different levels of access through an operation, from staging an attack to impacting the target.

The tactic is also an enabler for ATLAS AI Attack Adaptation Tactic techniques: ATLAS describes AI Attack Adaptation as using access obtained through AI Model Access to turn capabilities into target ready outputs. For the full framework view, see the MITRE ATLAS Guide.

Every technique in the tactic

The table lists all techniques ATLAS 2026.10 links to AML.TA0000 (none currently has sub-techniques). "Case studies" counts ATLAS case studies with at least one step that uses the technique under this tactic.

Counts were computed from the ATLAS 2026.10 data file by counting case study "employs" relationships whose tactic is AML.TA0000. One case study can use more than one technique, so the column sums to more than 27.

Where to start: ranked techniques for defenders

1. AML.T0040 AI Model Inference API Access. The most direct route and the one you control most fully. It is the staging ground for model discovery, attack verification and crafting adversarial data, and the delivery path for extraction. Rank it first wherever you expose a model endpoint, internally or externally, or hold keys to a hosted model service.
2. AML.T0047 AI-Enabled Product or Service. The most frequent in the case studies. Copilots, chatbots, AI security products and identity verification apps all expose a model indirectly. You often do not own the model, but you own the configuration, the data it can reach and the logs.
3. AML.T0044 Full AI Model Access. Rare but decisive: with the weights an adversary can optimise attacks offline and only show up when the attack already works. Rank it high if you ship models to devices, publish weights, or keep models in registries with broad read access.
4. AML.T0041 Physical Environment Access. Relevant only where a model takes sensor input from the real world (cameras, face recognition, autonomous systems), but there it bypasses every digital access control.

How adversaries chain AI Model Access

Stolen credentials to a hosted model

In the ATLAS case study of Storm-2139 (AML.CS0057), the group used exposed customer credentials scraped from public sources (AML.T0012 Valid Accounts), which gave it inference access to Azure OpenAI Service (AML.T0040). It then bypassed safeguards with jailbreak tooling (AML.T0054 LLM Jailbreak) and resold access through a reverse proxy service. The pattern matches the wider abuse of stolen cloud and AI keys described on the LLMjacking 2024 to 2026 breach page: the model was never attacked directly; the key was.

Token theft from an AI desktop app

In AIKatz (AML.CS0036), researchers with prior access to a machine read authentication tokens from the memory of LLM desktop applications, then used them to talk to the LLM backend as the victim (AML.T0047). From there they could inject prompts into ongoing conversations, poison chat memory and read the victim's history. The access step was a token, so the controls are token binding, short lifetimes and endpoint protection of the app process.

Weights extracted from a shipped app

In the Google Photos case study (AML.CS0058), researchers recovered TensorFlow Lite models from the Android app, some stored unencrypted and some captured after runtime decryption. That gave white box access (AML.T0044) and enabled white box optimisation of adversarial examples. A similar earlier study (AML.CS0013) found backdoorable models inside mobile apps, where only physical access to the camera input was then needed to trigger the backdoor (AML.T0041).

Indirect access through enterprise copilots and agents

Several case studies use an enterprise AI product as the access point: Slack AI (AML.CS0035) via messages in public channels, Copilot Studio (AML.CS0037) via a customer service inbox, and Microsoft 365 Copilot (AML.CS0026). In each, the adversary never authenticated to the model; anyone who could put content where the product reads it had access. That is why AML.T0047 so often leads straight to AML.T0051 LLM Prompt Injection.

Agentic operations

In the GTG-1002 campaign (AML.CS0069) the operators obtained access to Claude Code and used it within their intrusion framework, and in AML.CS0070 a threat actor's Hermes agent accessed DeepSeek through its native API for target selection and command generation. Here the adversary is the API customer: model access is the attacker's own tooling, and the defensive lever sits with the model provider's abuse detection.

Where identity fits

For AML.T0040 and much of AML.T0047, model access is granted to an identity: an API key, a cloud IAM role, an OAuth token or a service account. Long lived static keys in code, notebooks and CI variables are the commonest way that access leaks. Treat every model credential as a non-human identity with an owner, a scope (which models, which operations), a rate limit and an expiry, and prefer workload identity federation over static keys where the platform supports it. See the LLMjacking Guide for key handling and the AML.T0055 Unsecured Credentials page for how keys are found.

Controls across the tactic

Rollout order: first inventory every model endpoint and every credential that can call a hosted model service; second, enforce authentication and per identity quotas, starting in log only mode to find legitimate high volume users; third, turn on prompt, response and tool call logging with retention that matches your incident response needs; fourth, lock down registries and review any model shipped to clients; last, add honeypot keys and endpoints. Roll back quotas per consumer, not globally, if a business process breaks.

Small vs large organisations: a team that only consumes hosted models should concentrate on key management, provider side spending limits and provider audit logs. A team that serves its own models also owns endpoint authentication, rate limiting and registry access, and should put an AI gateway in front of every model. See the AI Gateway and LLM Gateway Guide.

Detection priorities

• Query volume and shape per identity: sudden increases, systematic prompt sets covering a capability, or many near identical queries with small changes, which suggest attack verification or extraction.
• New callers and locations: model API calls from keys, IP ranges or regions never seen before, including VPN and proxy ranges.
• Model enablement changes: new models enabled or new quotas requested on a cloud account, a common sign of stolen key reuse.
• Registry and artifact reads: downloads of model weights by identities outside the ML pipeline.
• Honeypot hits: any use of a decoy key or endpoint is high confidence.

Metrics: share of model endpoints requiring authentication (target 100 per cent); share of model credentials with an owner and expiry; number of static keys with model access, tracked downward; percentage of AI products with prompt and tool call logging enabled; median time to revoke a leaked model key.

Framework mapping

Common failure patterns

• Unauthenticated internal endpoints. Model servers and AI platform APIs left open on the assumption that they are internal; the McKinsey AI Platform Hack 2026 page describes an AI platform where researchers reached 22 unauthenticated endpoints.
• Static keys with no quota. A leaked key with unlimited spend is both an access path and a bill.
• Treating shipped models as secret. Models inside apps are recoverable, so assume white box access for anything on a client device.
• Logging the API but not the product. Copilots and agents are AML.T0047 access points; without prompt and tool call logs, abuse through them is invisible.
• No owner for model credentials. Keys created for a proof of concept outlive the project and nobody notices their use.

Practitioner checklist

• List every model endpoint and AI product in use, with the access level it exposes.
• Require authentication on every model endpoint, internal ones included.
• Give every model credential an owner, a scope, a quota and an expiry.
• Set per identity rate limits and provider side spending alerts.
• Log prompts, responses and tool calls for AI products, with tenant level retention.
• Restrict model registry reads to pipeline identities and alert on other downloads.
• Review any model shipped to devices on the assumption it will be extracted.
• Plant at least one honeypot key or endpoint and alert on any use.

Standards and references

• MITRE ATLAS: AI Model Access, Tactic AML.TA0000
• MITRE ATLAS: AI Model Inference API Access, AML.T0040
• MITRE ATLAS: Storm-2139 Azure OpenAI Guardrail Bypass, AML.CS0057
• MITRE ATLAS: Google Photos AI Model Extraction, AML.CS0058
• MITRE ATLAS: Control Access to AI Models and Data in Production, AML.M0019
• OWASP: LLM10:2025 Unbounded Consumption
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: MITRE ATLAS Guide · Model Extraction and Distillation Defence Guide · LLMjacking Guide · AI Gateway and LLM Gateway Guide