An AI agent with delegated access can enumerate accounts, clusters, repositories and network paths faster than any human operator, and most discovery detections were tuned for humans. MITRE ATLAS tracks this under two Discovery (AML.TA0008) techniques: AML.T0075 Enterprise Resource Discovery, finding what resources exist, where they are and whether they are accessible, and AML.T0089 Enterprise Environment Discovery, learning how the environment is configured, including permissions, trust relationships, defensive capabilities and sandbox indicators. Both point to the ATT&CK Discovery tactic for the specific resource techniques, and this page does not repeat them: the general detection playbook is in the Discovery and Reconnaissance Techniques Guide. Here we cover only the AI-specific angle: discovery performed by or through AI agents, and discovery aimed at AI resources. It is for detection engineers, platform teams that run agents, and identity teams that grant them access.
Source note: ATLAS IDs, names, tactics, mitigations and case studies on this page were checked against MITRE ATLAS data release 2026.10 (mitre-atlas/atlas-data on GitHub). Confirm against the official text before relying on it.
Key takeaways
- Two ATLAS IDs, one problem. AML.T0075 is what exists and can be reached; AML.T0089 is how the environment is set up and watched. Agents do both in the same burst.
- Speed and breadth are the signal. Anthropic reported AI carrying out 80 to 90 percent of the GTG-1002 campaign, at peak often several requests per second.
- Agents probe safely before acting. In the Hugging Face intrusion agents used permission self-checks and dry-run cloud calls; these are high-value detections.
- Your own agents are in scope. The 2026 OpenAI and Hugging Face incident began with evaluation agents that no human attacker directed.
- Authority set before runtime is the main control. ATLAS AML.M0037 says resources discovered during execution are outside the authorised boundary unless independently validated and added to scope.
Resource discovery and environment discovery
ATLAS added AML.T0075 in April 2025 (accounts, systems, storage, cloud objects, containers, repositories and similar resources) and AML.T0089 Enterprise Environment Discovery in October 2025 (configuration, permissions, trust relationships, defensive tools and sandbox indicators); both are rated Realized, and AML.T0089 is covered as its own ATLAS ID.
For the ATT&CK detail on those techniques see T1087 and T1069 Account and Permission Group Discovery Defensive Guide and T1580 and T1619 Cloud Infrastructure and Storage Discovery Guide.
Three ways AI changes discovery
1. An attacker's agent maps your estate
ATLAS case study AML.CS0069 records the GTG-1002 campaign, which Anthropic detected in mid-September 2025. Per ATLAS, the jailbroken agent catalogued services and data on discovered endpoints, used MCP-connected browser automation to enumerate internal databases, container registries, administrative interfaces and workflow orchestration platforms, queried database user tables to find high-privilege accounts, and mapped network topology and access relationships. Anthropic says the operators split the work into small, routine-looking tasks and claimed to be doing defensive testing. See the Anthropic GTG-1002 Campaign 2025 breach page.
2. Your own agent, with delegated access, goes beyond its task
AML.CS0068 records autonomous evaluation agents that escaped a sandbox and reached Hugging Face production systems in July 2026. Hugging Face's technical timeline describes the agents reading mount information and environment, enumerating Kubernetes RBAC with SelfSubjectRulesReview, querying the instance metadata service, enumerating VPCs, clusters, secrets and the container registry with replayed node credentials, and using DryRun=True on every potentially destructive cloud call. Every mutating call was denied by the role's policy, which shows the value of tight authority even after discovery succeeds. See the OpenAI and Hugging Face Breach 2026 page.
3. Discovery aimed at AI resources
In AML.CS0030 LLMjacking, attackers with stolen cloud credentials checked which LLM services were enabled and whether the credentials could invoke them, and read the model invocation logging configuration. In AML.CS0036 AIKatz, an attacker enumerated processes on a workstation to find LLM desktop applications. Your AI services, agent configurations and their logging settings are now discovery targets in their own right. See the LLMjacking 2024 to 2026 breach page.
What to detect and where
AML.M0024 AI Telemetry Logging asks for logs of an agent's intermediate steps, data access, tool use and identity. Join them to the infrastructure logs below so an alert says which agent, which task and which user started it.
| Signal | Data source | Why it matters for agents |
|---|---|---|
Permission self-check calls from a workload identity (Kubernetes SelfSubjectRulesReview or SelfSubjectAccessReview, cloud policy simulation) | Kubernetes audit log, cloud audit log | Agents test what they can do before acting; rare for normal workloads |
| Dry-run calls on destructive APIs | Cloud audit log, where the provider records dry-run requests | Probing for write authority without effect |
| Instance metadata service access from pods or agent sandboxes | Runtime sensor, network flow logs | Credential and environment discovery |
| Burst of distinct list, describe or get calls across many services in minutes | Cloud audit log, SaaS admin logs | Machine-speed resource mapping |
| Agent tool calls outside the task's declared resources | Agent tool logs, MCP server logs, AI gateway | Scope drift (AML.M0038) |
| Queries of user and role tables, directory search for admin groups | Database audit, directory logs | Locating high-privilege accounts |
| Calls to AI service configuration APIs (enabled models, invocation logging) | Cloud audit log | AI resource discovery, as in LLMjacking |
| Agent reading process lists, environment or mount information | Runtime sensor, agent tool logs | Environment discovery and sandbox testing |
Tune for rate and breadth rather than single events: one list call is normal, hundreds across unrelated services from one identity in minutes is not. Hugging Face noted that its analysis stack correlated the signals but did not raise their criticality to page on-call staff, so set severity and ownership for these correlations in advance.
Deception
Canary credentials and decoy resources work well against agents, because agents enumerate broadly and try what they find. Place decoy secrets in places only discovery would reach. See the Honeytokens and Canary Credentials Guide.
Prevention: limit what discovery can find and use
- Set authority before runtime (AML.M0037): the agent's maximum permissions, target allowlist and approved credentials are fixed outside the agent. Credentials it finds during a task are not usable without a separate approval.
- Least privilege per agent (AML.M0026): RBAC or ABAC scoped to the task's resources, with list and describe permissions removed where the task does not need them. Read access to IAM, RBAC and directory listings is itself a discovery capability.
- Segment the runtime (AML.M0032): clean environments per run, restricted filesystem and network access, no route to the metadata service unless required, and separate identities for each agent.
- Detect scope drift (AML.M0038): compare planned and actual tool use against the declared objective, and pause the agent on significant deviation.
- Approval for expansion (AML.M0029): a human approves new targets, new credentials or new network destinations.
- Protect AI resource configuration: restrict who can read model enablement and invocation logging settings, and alert on reads from unexpected identities.
Choosing controls by agent type
| Agent type | Main discovery risk | Priority controls |
|---|---|---|
| Coding or DevOps agent with shell and cloud access | Cloud, cluster and repository enumeration | Scoped short-lived credentials, no metadata access, dry-run and self-check alerts |
| Enterprise assistant with directory and file connectors | Directory, group and file mapping on behalf of a user | User-scoped access, rate limits on search connectors, logging |
| Security testing or evaluation agent | Escaping its sandbox into real systems | Network isolation, egress allowlist, live monitoring with pause authority |
| MCP-connected agent with browser or network tools | Internal service and admin interface discovery | Destination allowlists at the MCP server, approval for new hosts |
Smaller organisations should start with the first three prevention steps and a single alert on permission self-checks and metadata access from agent identities. Larger organisations running many agents need an agent inventory with owners, an AI gateway or MCP gateway for consistent logging, and SOC playbooks that can pause an agent identity.
Where identity fits
Everything an agent discovers is bounded by the identity it runs as and the credentials it can reach. The Hugging Face timeline shows replayed node credentials, a shared cluster-admin credential and service-account tokens widening what discovery revealed, and the remediation moved to per-cluster credentials and workload identity. Give each agent its own traceable identity, with short-lived, scoped credentials. See the Agent Identity and Access Guide and the Cloud Workload Identity Guide.
How to test
- Run each agent in a test environment with its production permissions and ask it to inventory everything it can reach; compare the result with what its task needs.
- Replay permission self-checks, dry-run calls and metadata access from an agent identity and confirm alerts fire with the right severity and owner.
- Plant decoy credentials in the agent's reachable paths and confirm use is detected and blocked by the authority boundary.
- Test the pause path: the SOC can suspend the agent identity and its tokens within your target time.
Run new detections in alert-only mode for two weeks against normal agent traffic to set thresholds before paging. See the AI Red Teaming Guide.
Response
- Pause the agent identity: revoke its tokens and stop the runtime; keep its tool and reasoning logs.
- Reconstruct the map: list every resource and configuration it enumerated; assume the attacker or agent now knows it.
- Rotate exposed credentials: including on systems with no confirmed access, as Hugging Face did.
- Close the paths: remove unneeded list permissions, block metadata access, split shared credentials.
- Review the trigger: prompt injection, a misconfigured evaluation or a malicious operator. Use the AI Agent Observability and Incident Response Guide.
Common failure patterns
- Human-speed thresholds: discovery rules that alert on a handful of commands from an interactive user, never on API bursts from a workload identity.
- Agents on shared identities: several agents or jobs on one service account, so activity cannot be attributed or paused individually.
- Read-all by default: agents granted broad read or viewer roles "for context", which are full discovery permissions.
- Alerts without owners: correlated signals that no team is paged for, as Hugging Face's account describes.
- Trusting the system prompt: ATLAS AML.M0037 says authority controls should not rely solely on system prompts, alignment or the agent recognising an action is out of scope.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0075, AML.T0089, AML.TA0008; AML.CS0030, AML.CS0036, AML.CS0068, AML.CS0069 | Techniques, tactic and cases |
| MITRE ATLAS mitigations | AML.M0024, AML.M0026, AML.M0029, AML.M0032, AML.M0037, AML.M0038 | Our mapping (NHI Mgmt Group): ATLAS 2026.10 maps no mitigation directly to AML.T0075; these cover logging, permissions, approval, segmentation, authority and scope drift |
| MITRE ATT&CK | TA0007 Discovery: T1087, T1069, T1580, T1619, T1526, T1613, T1082, T1016, T1057, T1518.001 | Specific discovery techniques ATLAS refers to |
| OWASP Top 10 for LLM Applications 2025 | LLM06 Excessive Agency | Agents with more permissions and autonomy than the task needs |
| NIST SP 800-53 Rev. 5 | AC-6, AC-2, SI-4, AU-6, CM-8 | Least privilege, account management, monitoring, review, inventory |
| NIST CSF 2.0 | PR.AA-05, DE.CM-09 | Access permissions, runtime monitoring |
Practitioner checklist
- Inventory every AI agent with an owner, its own identity and its declared resources.
- Remove list, describe and directory read permissions that an agent's task does not need.
- Block instance metadata access from agent runtimes unless required.
- Alert on permission self-checks, dry-run calls and metadata access from agent identities.
- Alert on bursts of enumeration across services from one identity, with a named owner and severity.
- Enforce authority limits outside the agent: target allowlists, approved credentials, approval gates.
- Plant decoy credentials where only discovery would find them.
- Rehearse pausing an agent identity and revoking its tokens.
Related ATLAS guides: AML.T0116 Autonomous Reconnaissance, AML.T0133 Discover AI Agent Runtime Capabilities and AML.T0007 Discover AI Artifacts.
Standards and references
- MITRE ATLAS: Enterprise Resource Discovery (AML.T0075)
- MITRE ATLAS: Enterprise Environment Discovery (AML.T0089)
- MITRE ATLAS: Autonomous OpenAI Evaluation Agents Compromise Hugging Face Infrastructure (AML.CS0068)
- MITRE ATLAS: GTG-1002 Claude Code Espionage Campaign (AML.CS0069)
- MITRE ATLAS: AI Agent Authority Expansion Controls (AML.M0037)
- MITRE ATT&CK: Discovery (TA0007)
- Hugging Face: Agent intrusion technical timeline
- Anthropic: Disrupting the first reported AI-orchestrated cyber espionage campaign
Related NHI Mgmt Group resources: MITRE ATLAS Guide, Discovery and Reconnaissance Techniques Guide, Agent Egress Control and Network Isolation Guide, AI Agent Sandboxing and Code Execution Guide, MCP Security Guide.