> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy.md). # 5.4 Agent-specific threats: tool poisoning and confused deputy Threats unique to tool-using agents include poisoned tool descriptions, misleading instructions, overbroad credentials, and confused-deputy privilege abuse. *Last reviewed: August 18, 2026* {% hint style="info" %} Agents can be tricked through the tools they trust. Review tool metadata, delegated permissions, and cross-agent messages as part of the threat model. {% endhint %} ## What security teams need to know about agent-specific threats: tool poisoning and confused deputy Tool-using agents have threats that ordinary chatbots do not. A tool description can mislead the agent. A connector can give the agent more access than the task needs. Another agent can pass untrusted instructions as if they were verified findings. A confused deputy appears when the agent uses its legitimate authority for someone else's goal. That is why tool scope and task context need to line up. In OWASP LLM Top 10 terms, these are the insecure plugin design and excessive agency risks. MCP's security guidance documents the recurring attack patterns by name. Confused deputy: an MCP proxy server using a static client ID with a third-party authorization server can let an attacker replay a consent cookie and obtain authorization codes. Token passthrough: a server accepts tokens that were not issued for it and forwards them downstream, defeating audience restrictions. Session hijacking: a predictable or exposed session ID lets an attacker inject events or resume someone else's session. All three are protocol-level shapes of the same problem: borrowed authority. ## Common agent-specific threats: tool poisoning and confused deputy security failures * A malicious tool description steers the agent to call it for unrelated tasks. * A tool description changes after approval (a rug pull), so the tool reviewers vetted is not the tool that runs. * A low-privilege user prompts an agent that has high-privilege connector access. * One agent passes hidden instructions to another agent. * A tool result tells the agent to ignore policy. * A broad service account lets the agent act outside the user's authority. ## Agent-specific threats: tool poisoning and confused deputy security controls checklist * Treat tool descriptions, schemas, results, retrieved content, memory, and inter-agent messages as untrusted inputs. * Pin or hash approved tool definitions so post-approval changes are detected. * Validate tool results against expected source, schema, identity, freshness, and authorization context. * Match connector and service-account scope to the task owner and preserve the initiating user. * Never accept or forward tokens that were not issued for the intended server and audience. * Use per-agent identities and task-specific permissions. * Prevent one agent or tool result from changing policy, identity, logging, budget, or tool access. * Restrict internal network, metadata-service, local-binding, callback, and redirect destinations. * Separate personal, shared, channel, tenant, and agent memory; review writes to persistent memory. * Require idempotency and replay protection for consequential actions. * Test poisoned tools, spoofed results, confused-deputy, cross-agent, memory-poisoning, SSRF, and approval-race cases. ## Threats that share the tool boundary **Tool-result spoofing** occurs when a compromised tool, connector, page, agent, or upstream service returns plausible but false content. Validate provenance and authorization context before using a result for a consequential action. **Memory poisoning** turns one malicious interaction into a persistent instruction or false fact. Separate memory by user, channel, project, tenant, and agent. Require review or policy for high-impact memory writes and support targeted removal. **SSRF and network pivoting** occur when an agent-controlled URL, callback, browser action, or tool request reaches metadata services, loopback listeners, private networks, management sockets, or unintended internal APIs. Apply destination policy after redirects and DNS resolution. **Replay and race conditions** occur when an approval, webhook, queue event, or tool request is reused or changes between review and execution. Bind approval to the exact action, arguments, identity, target, and expiry. ## Anthropic ### Overview Anthropic tool-poisoning review should cover MCP tool metadata, connector descriptions, skill instructions, Managed Agent toolsets, API tool schemas, and Claude Code plugin/hook behavior. A confused-deputy path appears when Claude uses legitimate user or agent authority for an injected or cross-agent goal. The useful specifics: connectors act with the person's source-system permissions, and Team or Enterprise owners can restrict connector actions, which narrows what a poisoned tool can trigger. Anthropic's skill-review guidance explicitly covers scripts, adversarial instructions, MCP references, and tool invocations. In Managed Agents multi-agent sessions, referenced agents are pinned to versions resolved when the coordinator is created or updated, the same pinning idea that defends against post-approval swaps. Claude Code MCP configuration can be scoped and controlled through settings rather than left to individual repositories. Cowork and Claude's Office add-ins add cross-surface deputy risks. Remote Cowork can combine connected services inside an Anthropic-managed sandbox, while local Cowork can use browser and application authority on the desktop. The Office add-ins can work across Excel, PowerPoint, Word, and Outlook when cross-app access is enabled. Test whether untrusted content in one file or message can cause an action in another application under the user's authority. Claude Tag creates a direct shared-authority deputy. In a channel, everyone in scope can ask the same organization-provisioned service accounts to act, regardless of who requested the task. Test whether a low-trust channel member, Slack integration, watched channel, or poisoned repository can steer Claude into using a higher-value connection, and verify that Access-bundle inheritance does not silently widen the channel's authority. ### Anthropic documentation * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise) * [Multi-agent sessions](https://platform.claude.com/docs/en/managed-agents/multi-agent) * [Claude Code MCP](https://code.claude.com/docs/en/mcp) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Work across Microsoft 365 apps with Claude](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI tool-poisoning review should cover ChatGPT app metadata, custom MCP tools, Apps SDK descriptors, Workspace Agents, Codex plugins/MCP servers, API tool definitions, and Agents SDK handoffs. Review what the tool says it does, what it can actually do, and whose authority it uses. Authority is the specific thing to check. App access and action control determine who can use a connected app and whether it can read only, take actions, or use a custom set of actions, so a poisoned description cannot expand an app past its assigned actions. Workspace Agent access tokens are distinct from platform and Compliance API credentials, and published workspace agents with agent-owned connections can expose data through the builder's credentials rather than end-user authentication, a confused-deputy shape worth modeling explicitly. Codex reaches MCP servers through its own configuration, which should be governed rather than ad hoc. ChatGPT Work and plugins widen the chain. A plugin may bundle skills, apps, app templates, and MCP servers, while the underlying app still acts with workspace and source-system permissions. Test whether instructions from a file, website, plugin skill, or connected source can redirect a Work task into a write, share, publication, scheduled run, or Computer Use action that the user did not intend. ### OpenAI documentation * [Admin Controls, Security, and Compliance in apps](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-apps-enterprise-edu-and-business) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Codex MCP](https://developers.openai.com/codex/mcp) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about agent-specific threats: tool poisoning and confused deputy ### What is tool poisoning? Tool poisoning is manipulation of tool metadata, descriptions, or outputs to steer an agent into unsafe tool use. A poisoned description can claim capabilities it lacks, tell the agent to call it for unrelated tasks, or smuggle instructions into results. A documented variant, the rug pull, swaps the description after approval so the reviewed tool and the running tool no longer match; pinning or hashing approved definitions is the control. ### What is a confused deputy in AI agents? It is an agent with legitimate access being tricked into using that access for an attacker's goal. MCP security guidance documents a concrete instance: a proxy server using a static client ID with a third-party authorization server can let an attacker replay a consent cookie and obtain authorization codes. The mitigation is obtaining user consent for each dynamically registered client. ### Why do multi-agent systems add risk? Agents may pass summaries or instructions to each other without preserving source trust and data boundaries. An instruction that arrives as another agent's finding can carry the same payload as an injected web page, with more implied credibility. Version pinning for referenced agents and restrictions on cross-agent policy changes limit the damage. ### How do service accounts affect confused deputy risk? Broad service accounts increase risk because the agent can act beyond the initiating user's real authority. The MCP token passthrough anti-pattern is the protocol-level version: a server that accepts tokens not issued for it lets callers borrow authority it was never granted. Scope identities per agent and per task, and reject tokens whose audience is not your server. ### How can teams test these threats? Create tests with poisoned tool descriptions, malicious tool results, low-privilege prompts, and cross-agent instruction passing. Add the documented MCP patterns: consent-cookie replay against OAuth proxies, tokens presented that were not issued for the server, session-ID guessing, and a post-approval description swap. Each test should record whether the deputy noticed, refused, or complied. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports resilience testing, vulnerability handling, and incident response. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Inference Security, Monitoring, and GRC guidance. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [5. Threats & Adversarial](/handbook/5.-threats-and-adversarial.md) * [2.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol.md) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity.md) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk.md) * [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.