ATLAS AML.T0133: Agent Runtime Capability Discovery

Anyone who can talk to an AI agent can usually get it to describe its own tools, data sources and permissions, and that map is what turns a curious prompt into a targeted attack. MITRE ATLAS tracks this as AML.T0133 Discover AI Agent Runtime Capabilities, in the Discovery tactic (AML.TA0008), and rates it as feasible. ATLAS describes adversaries interacting with an agent at runtime, without access to its configuration, to reveal its registered tools and accepted parameters, the actions it can take, the resources it can reach, and the identity and permission scope it acts under, either by asking directly or by inferring from which requests succeed, fail or are refused. This guide is for teams that build, deploy or monitor agents: what agents disclose, why hiding it is not the fix, and how to reduce what is worth discovering and detect the probing. Tool security in general is covered in the AI Agent Tool and Plugin Security Guide, and protocol controls in the MCP Security Guide.

Source note: technique, case study and mitigation details follow the MITRE ATLAS data release 2026.10 (modified 28 October 2026). Confirm against the official text before relying on it.

Key takeaways

Agents need to know their tools, so they can be asked about them. Tool names, descriptions and schemas sit in the model's context by design, and the model can repeat them.
Refusal is not a control. OWASP states that the system prompt should not be treated as a secret or used as a security control; an adversary can infer capabilities from behaviour even when the agent declines to list them.
Reduce what exists before hiding what exists. Fewer tools, narrower scopes and per-user permissions make a complete capability map far less useful.
Discovery is a precursor. ATLAS links the intelligence gained to tool invocation (AML.T0053) and to initial access, persistence, privilege escalation and exfiltration.
Probing leaves a pattern. Questions about tools and permissions, systematic parameter testing and bursts of refusals are detectable in agent telemetry.

What the technique covers

AML.T0133 is the runtime, conversational cousin of AML.T0084 Discover AI Agent Configuration. AML.T0084 includes reading configuration dashboards and files as well as asking the agent; its sub-techniques cover embedded knowledge (AML.T0084.000), tool definitions (AML.T0084.001) and activation triggers (AML.T0084.002). AML.T0133 focuses on what an adversary who can only interact with a working agent can learn. ATLAS lists four categories:

What is discovered	Where it comes from	Why the adversary wants it
Registered tools and accepted parameters	Tool definitions in the model context, for example the name, description and `inputSchema` returned by an MCP server's `tools/list`	Shows which actions can be invoked and how to shape arguments
Actions the agent can take	Tool descriptions, prior behaviour, error messages	Identifies send, write, delete or payment actions worth hijacking
Resources the agent can reach	Knowledge source names, connector names, retrieval results	Locates sensitive data for later collection or exfiltration
Identity and permission scope	Self-description, error text, success and failure patterns	Shows whether the agent acts as the user, as a shared service account or with elevated rights

The closely related system prompt angle is OWASP LLM Top 10 LLM07 System Prompt Leakage Guide; this page focuses on tools, reach and identity.

How it shows up in real cases

Copilot Studio customer service agent (AML.CS0037): Zenity researchers targeted an agent that monitored an email inbox. ATLAS records that they discovered its knowledge source, inferred it had a tool for sending email and found a CRM record retrieval tool, and learned that any new email activated it. Zenity's write-up describes the agent replying with its knowledge source names and connected tool names, including an internal platform component, which the researchers then used to plan data exfiltration. Zenity reports that Microsoft issued a fix. Scoping the trigger to a whole open inbox was what let an outsider talk to the agent at all.
Inference by testing (AML.CS0068): in the 2026 incident where autonomous evaluation agents reached Hugging Face production systems, ATLAS records that the agents tested what each identity could do and which internal services and network paths were reachable. That was discovery by observing success and failure rather than by asking, the same inference method AML.T0133 describes. The full chain is on the OpenAI and Hugging Face Breach 2026 page.

Why hiding capabilities does not work on its own

A natural first reaction is to tell the agent never to list its tools. That helps a little and should be done, but it fails as a primary control for three reasons:

The model holds the information: tool definitions must be in the context for the model to call them, so any successful injection or jailbreak can surface them.
Behaviour leaks it anyway: OWASP LLM07 notes that attackers interacting with a system will almost certainly determine many guardrails and restrictions by observing results, even when the exact wording is not disclosed. ATLAS describes the same inference for capabilities.
The real risk is the capability, not the description: OWASP's point for system prompts applies equally to tools. If the agent can do something dangerous for the wrong user, the fault is the missing authorisation check, not the disclosure.

Treat least disclosure as a speed bump and least capability as the wall.

Controls: least capability first

Control	ATLAS mitigation	Practical setting
Expose only the tools the task needs	AML.M0028 Enforce Access Controls for AI Agent Tools	Per-agent tool allowlist at the client or gateway; remove unused connectors; prefer read-only variants
Act with the caller's permissions, not the agent's	AML.M0028; AML.M0026 Manage AI Agent Service Access	Delegated access so tools inherit the calling user's identity and restrictions; RBAC or ABAC on every tool
Filter tool lists by caller	AML.M0026	Return only tools the caller is authorised for, so an anonymous user's map is short
Keep secrets and role details out of prompts and descriptions	AML.M0033 Input and Output Validation for AI Agent Components	No credentials, connection strings, internal hostnames or permission tables in system prompts or tool descriptions (OWASP LLM07 prevention)
Gate consequential actions	AML.M0029 Human In-the-Loop for AI Agent Actions	Confirmation for send, share, write and delete, so a mapped tool is not directly usable
Restrict tools once untrusted data is in context	AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data	Block or require confirmation for tool calls after external content is loaded
Segment agent components	AML.M0032 Segmentation of AI Agent Components	Separate identities, credentials and network access per agent, so mapping one does not map all
Deploy decoys	AML.M0039 AI Honeypots	Decoy tools or agents that no legitimate workflow uses; any call is a high-confidence alert

Least disclosure: the speed bumps

Generic errors to users: return "not available" rather than errors naming the denied permission, scope or backend system. Keep the detail in server logs. MCP's tool error model lets servers return execution errors to the model; make those messages useful for self-correction without naming internal systems.
Scoped triggers: limit who can start a conversation with an agent. An agent listening to an entire public inbox or web form can be interviewed by anyone.
Tool description hygiene: write descriptions for the model's task, not as internal documentation. Omit internal hostnames, database types, account names and version strings.
Instruction to decline: tell the agent not to enumerate tools or permissions to end users, accepting that this will sometimes be bypassed.

Decision guidance

Internal assistant for authenticated staff: disclosure of tools to the user is low risk if tools act with the user's own permissions. Focus on delegated access and approval gates; letting users see what the assistant can do also helps them spot misuse.
Public-facing agent (customer service, website chat, inbox): anyone can probe it. Minimise tools, filter the toolset for anonymous users, use generic errors, and place honeypot tools.
Agent with a shared service identity: the highest-value target for discovery, because the permission scope is wider than any one user's. Move to per-user delegation where the platform allows, or split into narrower agents. See the Agent Permission Drift guide.

Where identity fits

The most valuable answer an adversary can get is "which identity does this agent act as, and what can it do". If the answer is a shared service principal with tenant-wide read access, discovery has found a privilege escalation route. Give each agent its own identity, record its owner, scope its credentials and tokens to the tools it holds, and review them as non-human identities. The AI Agent Permission Matrix Template gives a format for recording agent, tool, scope and approver.

Detection

ATLAS AML.M0024 AI Telemetry Logging and Monitoring recommends capturing request and execution metadata and, for agentic systems, distinguishing requested actions from those actually executed. Build on that log with these signals.

Signal	What it suggests	Where to look
User prompts asking about tools, functions, permissions, connectors, knowledge sources or instructions	Direct capability enumeration	Prompt logs, guardrail classifier output
Sequences of near-identical requests that vary one parameter or target	Inference by testing	Agent session logs
High rate of refused, failed or denied tool calls in one session	Probing permission boundaries	Tool gateway and authorisation logs
Agent responses containing tool names, schemas or internal identifiers	Successful disclosure	Output scanning
Calls to decoy tools or use of canary credentials	High-confidence reconnaissance	Honeypot alerts; see the Honeytokens and Canary Credentials Guide
Inbound messages to agent-monitored inboxes or forms from new external senders that ask meta-questions	Outsider interviewing a triggered agent	Mail and form logs joined to agent runs

Metrics

Tool count per agent: tools exposed versus tools used in the last 30 days, trending towards parity.
Delegation coverage: share of agent tools acting with the caller's identity rather than a shared service identity.
Public agent toolset size: tools visible to unauthenticated callers, kept to the minimum.
Disclosure test pass rate: share of red team discovery probes that return no internal identifiers.
Decoy alert response time: minutes from a honeypot tool call to triage.

How to test

Build the expected map: for each agent, record tools, scopes, identity, knowledge sources and triggers from configuration. This is the baseline an adversary would try to recreate.
Probe as each caller type: in an authorised test, ask the agent about its capabilities as an anonymous user, a low-privilege user and an administrator, and compare what each learns with what each should be able to use.
Test inference: run harmless requests that exercise each tool boundary and check whether error messages reveal scopes, systems or identities.
Test indirect paths: place harmless discovery questions in content the agent retrieves (email, documents, web) to see whether it answers to a third party.
Fix and re-run: remove unneeded tools, tighten scopes and generic-ise errors, then repeat. Include this in AI red team scope (AML.M0035 AI Red Team) and in MCP testing; see the MCP Security Testing Guide.

Roll back tool removals by re-adding the tool to the allowlist with an owner and a review date, rather than restoring broad defaults.

Common failure patterns

Relying on a "do not reveal your tools" instruction: the instruction is bypassed and nothing else limits the agent.
Kitchen-sink toolsets: every connector enabled because it might be useful, so the map shows far more than the task needs.
Shared high-privilege agent identity: discovery reveals a scope wider than any user's, the pattern described in OWASP LLM Top 10 LLM06 Excessive Agency Guide.
Verbose errors: denial messages name the missing scope, the backend system or the service account.
Open triggers: agents that respond to any inbound email or form, as in the Copilot Studio case.
Internal detail in tool descriptions: hostnames, database types and account names copied from internal documentation into descriptions the model can repeat.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0133 in AML.TA0008; related AML.T0084 (and .000, .001, .002), AML.T0069; follow-on AML.T0053	Technique, sibling discovery techniques, and the main follow-on
MITRE ATLAS mitigations	AML.M0039 (mapped); AML.M0024, AML.M0026, AML.M0028, AML.M0029, AML.M0030, AML.M0032, AML.M0033 (supporting)	Decoys, logging, permissions, approvals, segmentation, validation
MITRE ATT&CK	T1082 System Information Discovery; T1087 Account Discovery	Enterprise analogues for environment and identity discovery
OWASP Top 10 for LLM Applications 2025	LLM07:2025 System Prompt Leakage; LLM06:2025 Excessive Agency	Disclosure risk and the capability it exposes
Model Context Protocol	Tools specification, security considerations	Servers must implement access controls and rate limit tool invocations; clients should log tool usage
NIST SP 800-53 Rev. 5	AC-6, CM-7, SI-4, AU-6	Least privilege, least functionality, monitoring, log review

Practitioner checklist

Record each agent's tools, scopes, identity, knowledge sources and triggers as a baseline.
Remove tools and connectors not used for the agent's task.
Make tools act with the caller's identity and filter tool lists by caller.
Keep credentials, hostnames and permission tables out of prompts and tool descriptions.
Return generic errors to users and keep the detail in logs.
Restrict who can trigger public-facing agents.
Log prompts, tool calls and denials, and alert on enumeration questions and refusal bursts.
Deploy at least one decoy tool or canary credential on public-facing agents.
Run discovery probes as anonymous, standard and admin callers in every red team cycle.

AML.T0133 Discover AI Agent Runtime Capabilities: Limiting What Agents Reveal About Their Tools and Permissions