ATLAS Discovery Tactic (AML.TA0008) Guide: What Attackers Learn From Inside Your AI Stack

Once an attacker has a foothold in an AI system, whether a prompt box, a stolen API key or a compromised agent host, the next move is to learn what that system can see, call and reveal, and the MITRE ATLAS Discovery tactic (AML.TA0008) describes how they do it. ATLAS summarises the tactic as the adversary "trying to figure out your AI environment". In AI systems, discovery often needs no shell at all: an agent can simply be asked which tools it has, and a model's outputs can be probed until its family, ontology and internals emerge. This hub explains what the tactic covers, ranks its 11 techniques for defenders, shows how discovery chains into collection and abuse in documented cases, and sets detection and mitigation priorities. It is written for AI platform owners, detection engineers, red teams and identity teams responsible for agent and workload credentials. For the framework overview, see the MITRE ATLAS Guide.

Key takeaways

• Discovery splits into two worlds. Half the techniques probe the AI itself (model family, ontology, outputs, system prompt, internals); the other half map the agent's configuration and the enterprise environment around it.
• Agent self-disclosure is the new reconnaissance. Discover AI Agent Configuration (AML.T0084) and Discover AI Agent Runtime Capabilities (AML.T0133) let an attacker learn tools, data sources and triggers just by asking or observing the agent.
• Environment discovery leads the case data. Enterprise Resource Discovery (AML.T0075), Enterprise Environment Discovery (AML.T0089) and AML.T0084 each appear in 4 ATLAS case studies, including LLMjacking and autonomous agent incidents.
• Two key techniques have no ATLAS mitigation. AML.T0075 and AML.T0089 rely on least privilege for machine identities and on detection of enumeration, because ATLAS maps no mitigation to them.
• Discovery is noisy if you look. Repeated probing queries, "what tools do you have" prompts, permission self-checks and calls to model-listing APIs are all loggable, and AI honeypots (AML.M0039) turn them into high-confidence alerts.

What AML.TA0008 means in practice

ATLAS adapts the ATT&CK Discovery tactic (TA0007) and keeps its meaning: techniques that help the adversary "observe the environment and orient themselves before deciding how to act". The AI version adds three targets that classic discovery does not have.

• The model: what family it belongs to, what classes or outputs it can produce, what information its outputs expose and, at the extreme, its non-public internals. This feeds attack staging, such as building a proxy model or crafting adversarial inputs.
• The LLM application: its system prompt, the delimiters and special characters it uses to separate context from user input, and keywords that map to functions. This feeds prompt injection and jailbreaks.
• The agent: its tool definitions, embedded knowledge, activation triggers and call chains, plus the identity and permission scope it runs under. This feeds collection and exfiltration through the agent's own tools.

The two environment techniques, Enterprise Resource Discovery and Enterprise Environment Discovery, bring classic post-compromise discovery into ATLAS for cases where an AI agent or an attacker on AI infrastructure enumerates accounts, cloud resources, permissions and network context.

Every technique in the tactic

The table lists every technique and sub-technique ATLAS (data release 2026.10) assigns to AML.TA0008, with maturity and the number of ATLAS case studies that use it under this tactic.

Method: case counts are distinct ATLAS case studies (77 in the 2026.10 release) with at least one procedure step using the technique, or for a parent technique any of its sub-techniques, tagged to AML.TA0008. In total, 20 of the 77 case studies include a Discovery step. Recover AI Model Internals is also listed under Collection.

Where to start: the techniques that matter most

1. Discover AI Agent Configuration (AML.T0084) and Runtime Capabilities (AML.T0133). If you run agents with tools, this is the discovery most likely to precede real damage. In the Zenity Copilot Studio case the researchers learned the agent's knowledge sources, tools and email trigger before using it to send data out; in the Claude Code GitHub Action case, tool definitions and triggers came first, then secrets from the process context.
2. Enterprise Resource Discovery (AML.T0075) and Environment Discovery (AML.T0089). These appear wherever stolen machine credentials or autonomous agents are involved: LLMjacking, GTG-1002, the OpenAI and Hugging Face incident and the AISI evaluation case. They are the bridge from an AI foothold to the wider estate.
3. Discover LLM System Information (AML.T0069). System prompt, delimiters and instruction keywords make injections reliable. In the M365 Copilot financial transaction case, discovering special characters and instruction keywords let researchers make false content look like a retrieved document.
4. Discover AI Model Outputs (AML.T0063). Realized maturity and present in the distillation campaign case that NSA, CISA and FBI attributed to China-based AI companies, as well as older evasion cases where exposed scores guided attacks on security classifiers.
5. Discover AI Artifacts (AML.T0007). Finding models in app bundles, registries or object stores leads straight to theft, as in the Google Photos model extraction case where models were recovered from an Android application.
6. Model probing set (AML.T0013, AML.T0014, AML.T0062, AML.T0144). Lower case counts, but relevant to anyone exposing proprietary models through an API. Discover LLM Hallucinations is the starting point for package hallucination squatting.

How discovery chains in real cases

The LLMjacking write-up shows how quiet AI-specific discovery can be: attackers sent deliberately invalid model invocation requests to find which models a stolen key could reach, requested model access under the victim's identity where needed, and checked whether prompt logging was enabled. In the OpenAI and Hugging Face incident, agents read process environment data, pulled instance credentials from the metadata endpoint and used the Kubernetes self-review API to list their own permissions, testing destructive calls with dry-run requests first. The GTG-1002 campaign shows the same mapping performed by a jailbroken agent at machine speed.

Detection priorities across the tactic

ATLAS does not publish per-technique analytics, so these priorities follow from the technique descriptions and case procedures.

• Self-disclosure prompts: classify and log prompts that ask an agent or chatbot to list its tools, data sources, instructions or permissions, or to repeat its system prompt (AML.T0084, AML.T0133, AML.T0069). A spike from one identity or an external sender is a strong signal.
• Model-listing and access APIs: alert on calls that enumerate models or request model access (for example foundation model listing and access requests in cloud AI services) from identities that never used them before, and on bursts of failed invocations (AML.T0075).
• Permission self-checks by workloads: self-review and "can I" API calls, metadata endpoint reads and dry-run requests from agent runtimes or AI build infrastructure (AML.T0089).
• Query pattern analysis: high-volume, systematically varied queries against a model endpoint, and queries that walk the output space (AML.T0013, AML.T0014, AML.T0063, AML.T0144).
• Artifact access: reads of model registries, object store prefixes holding weights and datasets, and listing calls on container registries by unexpected principals (AML.T0007).
• Decoys: canary tools, fake knowledge entries and honeytoken credentials planted where only discovery would find them. See the AI Agent Honeytokens and Canaries guide.

Mitigation priorities from ATLAS

Counting ATLAS mitigation relationships that point at techniques and sub-techniques in this tactic shows where the framework places its weight.

Enterprise Resource Discovery and Enterprise Environment Discovery have no ATLAS mitigation mapped. Treat them as identity problems: what can be discovered is bounded by what the agent's or workload's credentials can list. The MITRE ATLAS Mitigations Guide covers each mitigation in depth.

Where identity fits

Discovery in AI systems is mostly performed with someone else's identity: a stolen cloud key, an agent's service account or a user-delegated token. Three controls shrink what discovery can reveal.

• Scope machine credentials narrowly: an inference key should not be able to list or enable models; an agent's workload identity should not be able to list secrets or cluster resources it does not use. See the AI Agent Authorisation Guide.
• Block metadata and environment leakage: keep secrets out of environment variables in processes that handle untrusted input, and block agent runtimes from instance metadata endpoints.
• Treat the agent's answer as disclosure: whatever an agent can describe about its tools and permissions, an attacker who can prompt it can learn. Design tool scopes on the assumption that they will be enumerated.

Framework mapping

Common failure patterns

• System prompts treated as secrets: security relies on the prompt staying hidden, so its discovery breaks the control. Put rules in code and authorisation, not in the prompt.
• Verbose outputs: confidence scores, reasoning traces and debug fields returned to callers who do not need them.
• Agents that answer every question about themselves: no policy on describing tools, data sources or permissions to untrusted senders.
• Broad keys for narrow jobs: an inference key that can also list and enable models, as the LLMjacking attacks exploited.
• No logging of model management APIs: listing and access requests are not collected, so the first sign of a stolen key is the bill.
• Models shipped in client apps unprotected: artifacts discoverable in application bundles, as in the Google Photos extraction case.

Coverage checklist for AML.TA0008

• For each AI system, record which discovery techniques apply and the detection or mitigation in place.
• Decide and enforce what each agent may disclose about its tools, data and permissions, by caller.
• Log model listing, access request and invocation failure events from every AI service account.
• Restrict model outputs to the minimum the business needs; rate limit and monitor query patterns.
• Deploy at least one decoy tool, knowledge entry or credential per high-value agent.
• Review agent and workload permissions so enumeration returns little of value.

Practitioner checklist

• Test each agent with "what tools and data can you access" prompts from an untrusted channel.
• Remove secrets and security rules from system prompts.
• Strip scores and reasoning from external model responses unless required.
• Alert on first-time model listing or model access requests by any identity.
• Block instance metadata access from agent runtimes and sandboxes.
• Alert on self-permission checks and dry-run calls from AI workloads.
• Plant honeytokens in agent-reachable locations and route hits to the SOC.
• Inventory model artifacts in registries, buckets and mobile apps, and restrict listing rights.

Standards and references

• MITRE ATLAS: Discovery (AML.TA0008)
• MITRE ATLAS: atlas-data repository (techniques, mitigations and case studies)
• MITRE ATLAS: Discover AI Agent Configuration (AML.T0084)
• MITRE ATLAS: AI Honeypots (AML.M0039)
• MITRE ATT&CK: Discovery (TA0007)
• OWASP: LLM07:2025 System Prompt Leakage
• OWASP: LLM06:2025 Excessive Agency

Related NHI Mgmt Group resources: MITRE ATLAS Guide, MITRE ATLAS Mitigations Guide, OWASP LLM Top 10 LLM07 System Prompt Leakage Guide, AI Agent Tool and Plugin Security Guide, Model Extraction and Distillation Defence Guide.