Attacker Reconnaissance of AI Agent Tool Manifests and Memory Architecture

Attacker reconnaissance of AI agents targets more than exposed software. Tool manifests reveal what an agent can do, while memory reveals the patterns it is likely to follow. Together, they turn discovery into a map of possible actions and durable influence. Defending that operational layer requires governance of the text an agent reads, the memory it retrieves, and the tool sequences it executes, alongside filtering of user prompts.

Why AI agents are a fundamentally different reconnaissance target than traditional software

Traditional software reconnaissance reveals what a system has. Agent reconnaissance also reveals what an agent will do, because its capabilities are tied to natural-language instructions and autonomous execution. An agent does not merely hold credentials for an external system. It holds the authority to use them to complete a task, so disclosure of its operating context exposes available actions.

The structural condition behind this difference is instruction-data conflation. Instructions and data both arrive as natural-language text, without a reliable boundary that prevents the model from treating one as the other. Tool descriptions, retrieved documents, and memory entries can thus give the agent both information and commands. The same material that explains an agent's environment can influence how it acts within that environment.

Mandiant's 2025 AI risk report locates the most pressing challenges in AI asset visibility and governance of the implementation layer, including tooling and agent infrastructure. Microsoft's April 2026 threat analysis describes threat actors embedding AI across reconnaissance, malware development, and post-compromise operations.

What a tool manifest reveals to an attacker who asks the right question

A tool manifest is the most direct account of an agent's operational reach. Its names, descriptions, parameters, and permissions can show the full map of what the agent can do in a single exchange. Mandiant's 2025 AI risk report documents a simple tactic for obtaining that map. Asking an unguarded agent to list its internal capabilities, tools, scripts, or APIs can disclose its attack surface before the attacker probes for any vulnerability.

This disclosure is possible because tool descriptions sit in the agent's working context with its task instructions. The MCP specification places descriptions in context as text for the model to process, rather than leaving them as passive entries in a separate registry. A prompt that queries the agent's current context can therefore reach information intended to support tool selection. Without guardrails or other restrictions, the agent's own explanation of its capabilities becomes reconnaissance material.

The resulting map identifies reachable systems, including databases, APIs, file systems, and communication services. Argument signatures show what parameters each tool takes and what data the agent can read, write, or send. Names such as send_email_as_user and execute_sql also disclose implicit privilege scope. The manifest is therefore not just a map of tools, but a map of exploitable sequences in which individually authorized calls can produce an unauthorized outcome.

How MCP tool descriptions became executable instructions, not passive metadata

MCP tool descriptions influence behavior because the model processes them as language. Editing a description can function like rewriting instructions in the agent's system prompt, even though the actual system prompt remains untouched. That makes the manifest an injection surface as well as a reconnaissance surface. An attacker able to alter it can use knowledge of the available tools to steer subsequent actions through the same channel that disclosed them.

Trail of Bits research from April 21, 2025 showed that a description can have this effect before its tool is called. A payload made up operating-system and compliance requirements and got the agent to make unsafe permission changes through other tools. The description did not simply misrepresent the tool to which it belonged. It supplied a reason for the agent to act elsewhere in its environment, collapsing the gap between reading the manifest and following attacker-supplied instructions.

Authentication does not resolve that distinction. The MCP specification moved from no authentication in its November 2024 release to OAuth 2.1 with PKCE in March 2025. Those controls govern who can register a tool.

Check Point Research documented a related configuration trust failure in CVE-2025-54136. An attacker could add a benign MCP configuration to a shared repository, obtain a developer's approval in Cursor IDE, and then replace it with a payload-bearing version. Cursor's cached approval in versions 1.2.4 and below allowed subsequent IDE launches to execute the payload without another prompt, a behavior patched in Cursor 1.3. Developer-environment research also found that Claude Code, Cursor CLI, Gemini CLI, and GitHub Copilot CLI auto-executed project-defined MCP servers after acceptance of a folder trust prompt that defaulted to an affirmative response. One Enter key could thus spawn an attacker-controlled process with the developer's full OS privileges, illustrating the consequence of treating project configuration as trusted operational authority.

Memory architecture as the second reconnaissance surface: what an agent remembers tells an attacker what it will do next

The manifest describes available capabilities, but memory can reveal how the agent has used them. Records of completed tasks may disclose learned operational patterns, including which tools the agent invoked, their order, and their arguments. An attacker who studies those patterns can see which sequences the agent already treats as ways to complete a task.

In-context working memory holds the current conversation and the outputs from tools. It is ephemeral, but it can provide a complete view of the current session to a prompt that queries the active context. External retrieval through RAG or a vector store extends that view to documents and prior interactions indexed by semantic similarity. The reconnaissance value lies not only in what the corpus contains, but also in which material the retrieval mechanism brings forward for a task.

Procedural and episodic memory expose a more direct link between past behavior and future execution. These records represent prior successful task completions that the agent retrieves as templates for new work. These records can therefore show which tool chains the agent trusts and which arguments go with them. MCFA research by Xu et al., 2026 shows that sufficiently salient retrieved memory can govern tool choice, invocation order, and arguments. For reconnaissance, the important disclosure is that remembered experience can carry operational authority, making the retrieval path a guide to what the agent may do next.

What happens when poisoned memory is retrieved: persistence, override, and durable compromise

Once an attacker understands which memories guide execution, writing to that store becomes a way to influence future behavior. MCFA research by Xu et al., 2026 shows that a sufficiently salient retrieved memory can override the user's explicit instruction. MemoryGraft by Srivastava and He, 2025 demonstrates how poisoned procedural memories can be reused as task-solving strategies when retrieved as prior successful experiences. The replacement behavior needs no separate trigger at exploit time because retrieval supplies the poisoned experience as guidance.

Lakera AI research from November 2025 demonstrated indirect prompt injection through poisoned data sources that corrupted an agent's long-term memory. The agent came to hold lasting false beliefs about security policies and vendor relationships. When humans challenged those beliefs, it defended them as correct. The compromise had therefore moved beyond a misleading answer in the original interaction and into the agent's retained account of how its environment worked.

Persistence changes the attacker's delivery model. An attacker must deliver a session-bound prompt injection again in a later session, while a poisoned memory can be retrieved automatically whenever a task calls for it. The agent itself then delivers the attack, without the attacker having to act again. In a shared agent instance, that contamination can cross session and user boundaries.

The “toxic agent flow” illustrates how this persistence combines with tool authority. A chain can read data from a privileged source and write it to an attacker-controlled sink while each individual call remains authorized. Because an agent's production tokens are typically broader than an individual human user's, a memory-driven compromise can inherit those privileges across the sessions it influences.

Why standard input filtering misses reconnaissance conducted through tool manifests and memory

Filtering user input examines a different boundary from the one these attacks exploit. Tool descriptions can enter context at registration or startup, before any user interaction. A filter on what the user types cannot inspect or constrain instructions the agent has already received through its tool registry. Even with a clean user request, the agent can start work in a context shaped by configuration that an attacker controls.

Retrieved memory comes in through another path that the filter does not cover. The retrieval mechanism inserts documents and prior experiences into context on the basis of semantic relevance. A poisoned document can get past user-input filtering and become a key part of the agent's plan. The distinction is between the request that starts a task and the material the agent reads while solving it.

A compromised low-privilege sub-agent can send output it has tampered with to a high-privilege orchestrator, whose input filter treats the sender as a trusted peer even though the attack comes from outside. Filtering one entry point does not govern the other channels through which operational instructions arrive.

The Miasma Worm in June 2026 illustrates the configuration side of this gap. Adversarial MCP configuration files were planted across 73 GitHub repositories, including Microsoft Azure's azure/durabletask project. StepSecurity states that the files executed credential-harvesting payloads when developers opened affected repositories in vulnerable environments. No warning from a user-input filter was triggered because the dangerous material arrived through repository configuration.

Controls that address the actual reconnaissance surfaces: manifest governance, memory provenance, and runtime enforcement

Controls must operate where context is assembled, tools are registered, and memory is read or written. For the manifest, that begins with a tool registry fixed at the gateway. The agent should not discover or invoke tools that were not explicitly approved at deploy time. Tool descriptions should also be configuration under change control, rather than free-text fields that third-party server operators can alter at will. Every description change should produce a verifiable record and require human approval before taking effect in production.

Planner/executor separation addresses the path from untrusted text to tool authority. The CaMeL architecture from Google/DeepMind/ETH, 2025 separates a privileged planner from a quarantined model that parses untrusted content without tool access. A custom interpreter executes the plan and propagates metadata describing provenance and allowed readers. Explicit security policies then decide which tool calls and data flows are allowed.

Louck's 2026 research explores cryptographically binding memory writes to the principal that created them to prevent cross-session and cross-agent contamination without disrupting normal operation. The retrieval source list should also be fixed at the gateway so that the agent cannot retrieve from outside an approved corpus.

Runtime enforcement must be paired with visibility into complete workflows. Every production request should emit an OTel trace covering tool calls, retrieval sources, guardrail decisions, and timing. Span attributes should carry the model version, prompt version, policy version, user ID, and tenant ID so deviations from approved behavior are observable. Approved workflows must then be re-verified after every change to establish that safeguards have not broken legitimate operation. A control that stops an attack is not ready for production until the workflows it might disrupt still pass.

Every surface the agent reads is a potential instruction channel, so each requires the governance applied to code. Change control constrains what can enter, provenance identifies whose authority it carries, and runtime policies constrain what it can cause. Verified re-testing establishes that those boundaries hold without disabling approved work. That is the security boundary an autonomous agent requires.