AML.T0084 Discover AI Agent Configuration: How Attackers Map Agent Tools and Triggers

Before an attacker can turn an AI agent against its owner, they need to know what the agent can reach, which tools it holds and what wakes it up. MITRE ATLAS tracks that reconnaissance as AML.T0084 Discover AI Agent Configuration, in the Discovery tactic (AML.TA0008). ATLAS describes two routes: reading configuration directly from dashboards or files, and simply asking the agent questions such as "What tools do you have access to?". This page explains the four sub-techniques, the ATLAS case studies behind them, how to detect the questioning and how to reduce what an agent gives away. It is for teams who build, run or monitor AI agents, and for SOC analysts who need to recognise the first stage of an agent attack.

Key takeaways

• Discovery is the step before damage. In every ATLAS case linked to AML.T0084, the attacker mapped tools, data or triggers first and then used them for collection or exfiltration.
• The agent will often describe itself. In AML.CS0037 an injected email asked a customer service agent to list its knowledge sources and actions, and the agent replied with the names.
• Triggers are an attack surface. An agent that runs on every incoming email or GitHub comment can be reached by anyone who can send one.
• Hiding the configuration is a delay, not a control. OWASP LLM07:2025 says the system prompt should not be treated as a secret or a security control; the real defence is limiting what the tools can do.
• Self-description requests are a detection opportunity. Questions about tools, data sources and instructions coming from untrusted content are rare in normal traffic and worth alerting on.

How the technique works

ATLAS created AML.T0084 in September 2025 and rates it as demonstrated (release 2026.10, last modified May 2026). It applies to the Agentic AI platform. The enterprise equivalents in ATT&CK are T1082 System Information Discovery and T1518 Software Discovery; the AI-specific difference is that the system being questioned can answer in natural language. See the T1518 Software Discovery guide for the host side.

The attacker can learn the configuration in three ways:

• Ask the agent: directly as a user, or indirectly through content the agent processes (an email, a ticket, a calendar invitation) that carries injected instructions. See AML.T0051 LLM Prompt Injection.
• Read the configuration: agent builder dashboards, MCP client files, workflow definitions or public repositories. ATLAS AML.T0002.002 AI Agent Configuration covers acquiring publicly accessible configuration files, which then feed AML.T0084 and MITRE ATLAS AML.T0083 Credentials from AI Agent Configuration.
• Analyse the code: static analysis of an application or framework to find how inputs flow to tools and execution sinks (sub-technique .003).

The four sub-techniques

Case studies

Copilot Studio customer service agent (AML.CS0037)

Zenity researchers built a customer service agent in Copilot Studio that processed every email arriving in an inbox open to customers. A crafted email posing as a system update told the agent to list its knowledge sources and send the answer to an external address; a second email asked it to list its actions with their descriptions. The replies exposed the knowledge source names and connected tools such as an email sender and a CRM record reader. ATLAS then records the collection steps: the full CSV and all CRM records retrieved. Zenity's write-up states Microsoft issued a fix in April 2025. The lesson is the chain: an open trigger plus a self-describing agent gave the attacker a target list. See the Securing Microsoft Copilot Studio Agents Guide for the customer-side settings.

Agent in a CI pipeline (AML.CS0067)

Microsoft's security researchers examined a GitHub Action that runs a coding agent on repository events. They identified that the agent was triggered by issues, pull requests and comments, and that its shell tool ran in a sandbox with a scrubbed environment while its file-read tool did not. That tool-level discovery let them steer the agent to read and emit a workflow secret. Microsoft reported it to Anthropic on 29 April 2026 and it was mitigated in Claude Code 2.1.128 on 5 May 2026, per Microsoft's post. The defensive point is that discovery included understanding the isolation boundary of each tool, not only the tool names.

Productivity assistant with connected services (AML.CS0063)

In the SafeBreach research recorded by ATLAS, the researchers first identified available agents, tools and connected services (calendar, mail, smart home, browser and conferencing) before using calendar invitations to drive collection.

Call chains in LLM frameworks (AML.CS0052)

The LLMSmith study (ACM CCS 2024) used lightweight static analysis to build call chains in 11 LLM-integrated frameworks, finding 20 vulnerabilities, 19 of them remote code execution, of which 17 were confirmed and 11 received CVE IDs. Attacks succeeded against 17 of 51 potentially affected applications, per the paper. This is the sub-technique most relevant to developers: if your application connects model output to an interpreter, assume it can be found.

Detection

ATLAS links no detection data source to AML.T0084 directly. The signals below are NHI Mgmt Group recommendations and depend on logging prompts, responses and tool calls (AML.M0024 AI Telemetry Logging and Monitoring, linked in ATLAS to related techniques).

ATLAS maps AML.M0039 AI Honeypots to this technique: decoy agents, decoy tool names or canary data sources reveal who is hunting for agent configuration. See AI Agent Honeytokens and Canaries.

Measuring it

• Inventory coverage: share of production agents with a recorded owner, trigger list, tool list and data source list.
• Open triggers: number of agents that any external party can activate (target: each one justified and reviewed).
• Self-description alerts: count and triage time of configuration-probing prompts from untrusted content.
• Exposure: agent builder or admin interfaces reachable from the internet (target zero).
• Red team result: share of agents that disclose tool or data source names when probed in testing.

Prevention and hardening

ATLAS maps two mitigations to AML.T0084: AML.M0000 Limit Public Release of Information (limit public disclosure of agent tools, services, configuration, workflows, activation keywords and call chain details) and AML.M0039 AI Honeypots. The other controls below are NHI Mgmt Group recommendations that reduce what discovery is worth.

• Limit public detail: keep tool definitions, trigger keywords and system instructions out of public documentation, marketing pages and repositories (AML.M0000).
• Design for disclosure: assume the tool list and instructions will leak, following OWASP LLM07:2025. No credentials or access rules in prompts; enforce authorisation outside the model.
• Narrow the triggers: restrict who can activate an agent (allowlisted senders, authenticated users, specific labels) rather than listening to a whole inbox or every repository event.
• Remove unused tools: fewer tools means less to discover and less to abuse; see the OWASP LLM Top 10 LLM06 Excessive Agency Guide.
• Isolate every tool equally: apply the same sandbox and environment scrubbing to file, shell and network tools, as the CS0067 case shows.
• Break dangerous call chains: do not pass model output to interpreters; where code execution is required, run it in an isolated, network-restricted sandbox.
• Protect agent builder consoles: require authentication and role-based access for configuration views; review who can export agent definitions.

The MCP specification (2025-06-18) says clients should make clear which tools are exposed to the model and must treat tool annotations as untrusted unless they come from trusted servers. Showing users the tool list is good practice; publishing it to the world is not the same thing.

Implementation

1. Inventory agents: for each agent record owner, triggers, tools, data sources and where its configuration lives. The Shadow AI Discovery Guide helps find unregistered ones.
2. Turn on logging: capture prompts, retrieved content, responses and tool calls with the agent and caller identity.
3. Probe your own agents: in a test tenant, ask each agent, directly and through injected content, to list its tools, sources and instructions. Record what it discloses (AML.M0035 AI Red Team).
4. Reduce: remove unused tools, narrow triggers, move secrets and access rules out of prompts.
5. Deploy detections in alert-only mode: tune configuration-probing rules on two to four weeks of real traffic before raising severity.
6. Add decoys: place a canary tool name or data source and alert on any reference to it.
7. Repeat after change: rerun the probe set whenever tools, triggers or models change. Rollback is simple: detection rules can be disabled, and trigger restrictions can be reverted from the agent configuration history.

Framework mapping

Common failure patterns

• Open-door triggers: an agent that acts on any email to a public inbox, as in AML.CS0037.
• Secrecy as a control: relying on a hidden system prompt to protect data instead of tool-level authorisation.
• Uneven tool isolation: sandboxing the shell tool while a file-read tool runs with full access, as in AML.CS0067.
• Leftover tools: connectors added during a pilot that remain on the production agent.
• No prompt logging: configuration probing is invisible when only tool calls, or nothing, are logged.
• Configuration in public repositories: agent definitions and prompt files committed alongside application code.

Practitioner checklist

• Keep an inventory of every agent's triggers, tools and data sources with a named owner.
• Restrict who and what can activate each agent.
• Remove tools and data sources the agent's task does not need.
• Keep credentials and access rules out of system prompts.
• Apply the same isolation to every tool type.
• Log prompts, retrieved content, responses and tool calls.
• Alert on configuration-probing requests arriving in untrusted content.
• Test agents for self-disclosure before release and after every change.
• Keep agent configuration and builder consoles off the public internet.

Standards and references

• MITRE ATLAS: Discover AI Agent Configuration
• MITRE ATLAS: Data Exfiltration via Agent Tools in Copilot Studio
• MITRE ATLAS: Claude Code GitHub Action Secret Exposure
• MITRE ATLAS: Limit Public Release of Information
• OWASP: LLM07:2025 System Prompt Leakage
• Model Context Protocol: Tools specification
• Microsoft Security Blog: Securing CI/CD in an agentic world
• arXiv: Demystifying RCE Vulnerabilities in LLM-Integrated Apps

Related NHI Mgmt Group resources: MITRE ATLAS Guide · MITRE ATLAS AML.T0081 Modify AI Agent Configuration · AML.T0053 AI Agent Tool Invocation · OWASP LLM Top 10 LLM07 System Prompt Leakage Guide