Not every dangerous agent skill needs an obviously malicious binary or script. Tool poisoning and agent goal hijacking abuse something else entirely: the way an AI agent reads tool descriptions, follows instructions, and maps a user's request onto the tools available to it.

Tool poisoning

Tool poisoning embeds a covert directive inside a tool's description, the metadata an agent reads to decide when and how to use that tool. Because the agent natively parses and trusts that description as part of its planning process, a hidden instruction sitting there can get executed as though it were a legitimate part of the task, even though the user never asked for it and never saw it.

This is part of why hash-based tool pinning matters: a tool description that was reviewed and approved once can be silently altered later, a pattern sometimes called a rug pull, and the agent has no way to know the description it's reading today isn't the one that was originally vetted.

Agent goal hijacking

Goal hijacking is a related but distinct attack. Instead of poisoning a tool's own description, it subverts the user's original objective mid-task, steering the agent toward actions the user never intended, unauthorized reconnaissance, or tool invocations that drift from the actual request. The user asked for one thing. The agent, manipulated by content it encountered along the way, ends up doing something adjacent but unauthorized.

Detecting these attacks requires strict input and output content scanning and watching for tool-call sequences that deviate from the workflow a user's request would normally produce, not just inspecting the tools themselves in isolation.

Why this category is harder to catch than code-level attacks

A credential harvester or a backdoor eventually leaves a trace in system calls, network traffic, or the filesystem. Tool poisoning and goal hijacking can happen entirely inside natural language, no unusual syscall, no suspicious file write, just an instruction that reads as legitimate to a parser and steers behavior somewhere it shouldn't go. That's why detection here leans more heavily on semantic analysis of SKILL.md and tool description content for coercive or directive language, combined with monitoring for tool-call sequences that don't match the expected shape of the user's actual request.

FAQ

How is tool poisoning different from a straightforward prompt injection? Prompt injection typically targets a single running conversation. Tool poisoning is persistent: the malicious directive lives inside a tool's description or metadata, so it can affect every future invocation of that tool, not just one exchange.

Can this happen even if the skill's code is completely clean? Yes. That's the defining characteristic of this category. The executable code can be entirely benign while the natural-language description or instructions surrounding it carry the actual attack.

What's the single most effective mitigation? Hash-pinning tool descriptions at approval time and alerting on any subsequent change closes off the most common version of this attack, since it removes the attacker's ability to alter an already-approved description without detection.

Related reading: "Backdoors That Outlive the Session: Persistence in Agent Skills," "When Trusted Isn't: Understanding MCP Impersonation"