AML.T0006 Active Scanning: Detecting Scans for Exposed AI Infrastructure and Agent Triggers

Before attackers touch a model or an agent, they probe for it, and AI infrastructure now attracts its own scanning traffic. MITRE ATLAS AML.T0006 Active Scanning sits in the Reconnaissance tactic (AML.TA0002), rated Realized, and mirrors ATT&CK T1595 Active Scanning. The September 2026 ATLAS release split it into four sub-techniques: enumerating hosted AI resources on SaaS platforms, querying platform metadata APIs, scanning for exposed AI infrastructure, and probing agent trigger channels such as email inboxes. This guide covers each sub-technique from the defender's side: what the probing looks like, where it shows up in your telemetry, and the controls that make it less productive. It is for SOC analysts, detection engineers and teams that run AI platforms. For the network-level basics of scan detection, see the Attack Surface Management Guide.

Key takeaways

• Scanning is the step you can see coming. ATLAS separates Active Scanning from passive reconnaissance because it involves direct interaction with your systems, which means it leaves logs.
• AI agents now do the scanning. ATLAS case studies from 2026 record agentic frameworks running IP-range and vulnerability scans, comparing results and choosing targets with little operator input.
• SaaS agents are scanned through the platform, not your network. Enumeration of hosted agents and metadata APIs happens on the provider's control plane, so your perimeter logs will not show it.
• Agent inboxes and webhooks are reconnaissance targets. An automatic reply that reveals an AI agent tells an attacker where to aim prompt injection.
• Reduce what a scan can learn. Authentication on every endpoint, non-predictable resource names, quiet error responses and decoy endpoints all lower the value of scanning.

What ATLAS describes

ATLAS describes AML.T0006 as actively scanning for publicly reachable AI systems and resources, including those that are misconfigured or running known vulnerable versions. Because AI systems often run in the cloud, adversaries use enumeration methods to find them and learn about their supporting platforms. For agentic and SaaS-hosted systems, ATLAS states that the victim system can include the shared platform and provider control plane on which the victim's agents are deployed. Results feed other reconnaissance, such as AML.T0000 Search Open Technical Databases and AML.T0064 Gather RAG-Indexed Targets, and often lead directly to AML.T0132 Misconfigured or Publicly Exposed AI Services.

For generic port and vulnerability scanning of your estate, the ATT&CK technique T1595 and its sub-techniques T1595.001 Scanning IP Blocks, T1595.002 Vulnerability Scanning and T1595.003 Wordlist Scanning already apply. This page covers only what is specific to AI.

AML.T0006.000 Enumerate Hosted AI Resources

ATLAS describes platforms that host agents behind predictable URL structures derived from environment, tenant, resource-group or agent names, with default deployment settings that keep those conventions the same across customers. An adversary learns the convention from vendor documentation, code repositories or live resources, then brute-forces the namespace to find live agents and their metadata. ATLAS cites the Copilot Studio Hunter module of the open-source power-pwn project as an example of scanning SaaS platforms for accessible agentic chat interfaces.

• What the customer controls: whether a discovered agent answers without sign-in. In Copilot Studio, agents set to "No authentication" let anyone with the link chat with them, and a Power Platform data policy that requires authentication removes that option for makers. See the Securing Microsoft Copilot Studio Agents Guide.
• Naming: avoid agent and environment names that are guessable from the company name, and do not publish agent URLs in public repositories or documentation.
• Detection: watch conversation analytics for sessions on agents that are meant to be internal, and for bursts of short, unauthenticated sessions with no business outcome.

AML.T0006.001 Query Platform Metadata APIs

Here the adversary asks the platform rather than guessing. ATLAS describes documented or undocumented provider APIs that return tenant, environment or deployment identifiers, including for resources that are misconfigured or unintentionally reachable without authentication. Its example is an online OSINT tool that used an undocumented Power Platform API to reveal environment IDs for Entra ID tenants, which could then be used to scan for public agents; ATLAS notes that authentication was added after the abuse was identified.

• What this means for defenders: some identifiers you treat as internal are recoverable by outsiders. Do not rely on an environment ID or tenant ID being secret as an access control.
• Controls: authentication on every agent and endpoint (ATLAS AML.M0019 Control Access to AI Models and Data in Production), and tenant-level settings that restrict sharing of agents and apps to authenticated users.
• Detection: mostly a provider responsibility. Customers should follow provider security advisories and review which of their resources are reachable anonymously.

AML.T0006.002 Scan for Exposed AI Infrastructure

ATLAS describes self-hosted AI runtimes that listen on predictable, well-known ports and expose standard API paths, so adversaries can find candidate hosts efficiently and infer the platform running on them, then fingerprint software and version to choose targets. This is the sub-technique your own network telemetry can see best.

The cases show how quickly this happens. ATLAS records in AML.CS0023 (ShadowRay) that adversaries scan public IP addresses for Ray dashboards. Pillar Security's honeypots saw exploitation attempts within hours of endpoints appearing in Shodan or Censys results, and found that by late January 2026 an MCP-focused reconnaissance campaign made up 60% of attack traffic. In AML.CS0070, Palo Alto Networks Unit 42 recovered a session in which a DeepSeek-powered Hermes agent ran a public Langflow scanner, probed roughly 40 systems, found three running affected versions, and switched to scanning more than 50 other targets. Where an agent chooses its own next step, see MITRE ATLAS AML.T0116 Autonomous Reconnaissance. In AML.CS0069, a jailbroken Claude agent in Anthropic's reporting on GTG-1002 performed IP-block and vulnerability scanning to enumerate services and select an SSRF flaw.

• Detection: alert on inbound connections to AI runtime ports from the internet at the firewall or cloud flow logs; on reverse proxies, flag clients that request the standard listing, health or model-metadata paths of several runtimes in a short window, and requests with placeholder keys such as sk-test or dev-key, which Pillar recommends alerting on.
• Prevention: keep runtimes on private interfaces behind an authenticating gateway; return the same generic error for unknown paths and failed authentication so fingerprinting yields less; never expose MCP servers to the internet.
• Further hardening: the vLLM, Triton and NVIDIA NIM Inference Server Security Guide, the Ray and AI Compute Cluster Security Guide and the Flowise and Langflow Security Guide.

AML.T0006.003 Probe AI Agent Trigger Channels

An agent that reads a shared inbox, a webhook or a chat channel can be triggered by anyone who can send to it. ATLAS describes adversaries sending crafted inputs to those triggers to elicit a response that shows an agent is at work; the reply can reveal agent-managed accounts and more attack surface. In ATLAS AML.CS0037, Zenity researchers looked for support email addresses on an organisation's website that might be agent-managed, then sent emails and watched for signs of agentic AI in the automatic replies, before moving on to extract data through the agent's tools. Microsoft confirmed the behaviour in March 2025 and issued a fix in April 2025, according to Zenity's timeline. In AML.CS0063, researchers probed Gemini interfaces directly to understand agent selection and execution before sending calendar-invitation attacks.

• Reduce what a probe learns: automatic replies from agent-managed channels should be templated and should not echo the input, describe the agent's tools or knowledge sources, or vary with the content of the request.
• Gate the trigger: filter which senders and message types can start an agent run; treat inbound content as untrusted data, never as instructions.
• Detection: look in agent logs for runs triggered by first-time external senders that ask about the agent itself (its tools, instructions or data sources), and for many short messages from one sender or domain.
• Related techniques: once a trigger is found, the next steps are usually prompt injection and tool abuse; see MITRE ATLAS AML.T0093 Prompt Infiltration via Public-Facing Application and MITRE ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation.

Mitigations ATLAS lists

A decoy inference endpoint on an unused public address, or a canary mailbox that looks agent-managed, has no legitimate traffic, so any interaction is a high-confidence signal. See the Honeypot deployment and Deception Technology Guide pages for isolation and alert design.

How to test your exposure

1. Agree scope and authorisation in writing, covering your own address space, SaaS tenants and agent channels only.
2. Scan yourself from outside for the runtime ports and API paths you use, through your external attack surface tool. Any response from an AI service is a finding.
3. Check search engine indexes such as Shodan and Censys for your ranges and domains.
4. Review SaaS agent sharing: list every agent reachable without sign-in and every agent URL published publicly.
5. Probe your own trigger channels with benign test messages from an external account and review what the replies disclose.
6. Confirm detection: each test should raise the alerts in the table below; tune or add rules where it did not.

Detection and metrics

• Number of AI endpoints answering unauthenticated requests from the internet (target zero).
• Time from a new AI endpoint becoming reachable to detection by your own scan.
• Percentage of agent trigger channels with sender filtering and templated replies.
• Number of honeypot interactions per month, as a trend of scanning pressure.
• Percentage of scanning alerts triaged within the SOC's target time.

Framework mapping

Common failure patterns

• Ignoring scans as noise. Internet background scanning is constant, but scans that hit AI-specific ports and paths are a precursor worth correlating with later access.
• Assuming SaaS agents are invisible. Platform URL conventions and metadata APIs make hosted agents discoverable; authentication, not obscurity, is the control.
• Chatty agent replies. Auto-replies that describe what the agent can do are a free reconnaissance service.
• Scanning only for CVEs. Many AI runtimes are exposed by configuration rather than a vulnerability, so version-based scanners miss them.
• No owner for AI telemetry. Model server and agent logs are often kept by product teams and never reach the SOC.

Practitioner checklist

• Add AI runtime ports and API paths to external scans and firewall alerting.
• Forward reverse proxy, AI gateway and agent run logs to the SIEM.
• Require authentication on every production AI endpoint and agent.
• Use non-guessable names for agents and environments; keep agent URLs out of public repositories.
• Template auto-replies on agent-managed inboxes and webhooks.
• Filter which senders can trigger agent runs.
• Deploy a decoy AI endpoint and a canary agent inbox.
• Run an authorised self-scan quarterly and confirm alerts fire.

Standards and references

• MITRE ATLAS: Active Scanning (AML.T0006)
• MITRE ATLAS: Data Exfiltration via Agent Tools in Copilot Studio (AML.CS0037)
• MITRE ATLAS: DeepSeek-Powered Hermes Agent in Langflow and n8n Exploitation Attempts (AML.CS0070)
• MITRE ATT&CK: Active Scanning (T1595)
• Pillar Security: Operation Bizarre Bazaar
• Zenity Labs: A Copilot Studio Story, Discovery Phase in AI Agents
• Microsoft Learn: Configure user authentication in Copilot Studio
• Qdrant: Security

Related NHI Mgmt Group resources: MITRE ATLAS Guide · Attack Surface Management Guide · Shadow AI Discovery Guide · MITRE ATLAS Mitigations Guide