Action Poisoning

What Action Poisoning Means

Action poisoning is not just prompt manipulation, it is control-flow corruption. The attacker alters the agent’s instructions, state, or queued tool actions so the automation behaves as if the harmful step was legitimate.

The practical danger is that the system may still appear to be following policy while it is actually executing attacker-influenced operations. That makes action poisoning especially effective against agents that can read context, update records, call tools, or chain decisions across multiple steps.

How Action Poisoning Works

Action poisoning usually targets the boundary between reasoning and execution. Instead of forcing a single bad output, the attacker nudges the agent into storing, replaying, or trusting malicious instructions that later become actions, such as sending data, changing workflow state, or approving a request.

This can happen through poisoned prompts, corrupted memory, manipulated tool output, or tainted intermediate state. In agentic systems, the abuse is more dangerous when the agent treats untrusted context as operational truth and does not cleanly separate user intent, system intent, and tool responses.

When those boundaries are weak, the attacker can turn a seemingly routine task into an unintended business process change. The issue is less about a single unsafe command and more about a compromised decision path that the agent continues to trust.

Why Action Poisoning Is Dangerous

Action poisoning can lead to data exfiltration, unauthorized record changes, fraudulent transactions, and privilege abuse. Because the agent often acts with delegated authority, the damage may look like a normal automation event unless the surrounding controls preserve strong provenance and approval boundaries.

It is also dangerous because it can be persistent. If the poisoned state is stored in memory, task queues, workflow metadata, or tool history, the attacker may influence later runs even after the original injection point is gone.

For agentic systems, this is one reason OWASP Agentic AI Top 10 treats tool misuse, identity and privilege abuse, and memory or context poisoning as closely related attack classes.

Where Defenders Should Focus

Defence starts with separating instruction sources from execution authority. Agent context, tool output, and user input should not be treated as equally trustworthy, and high-impact actions should require explicit confirmation or policy checks outside the model’s own reasoning path.

Strong logging matters because the attacker’s goal is often to make a malicious action look routine. Reviewing tool calls, state changes, and unusual action sequences helps reveal when the agent has been steered away from normal behaviour.

For threat modelling and detection work, MITRE ATLAS adversarial AI threat matrix is useful for mapping prompt injection, context poisoning, and tool misuse to concrete adversarial techniques. If the agent relies on APIs to carry out work, OWASP API Security Top 10 helps frame downstream risks such as broken authorization and unsafe action exposure.

Operational Implications for Agent Owners

Action poisoning is ultimately an ownership problem as much as a model problem. The team running the agent needs to know which actions the system may take on its own, which actions require approval, and which intermediate states must never be allowed to drive execution without validation.

GitHub and GitHub Actions Security Guide is a useful internal reference when the automation surface includes workflow execution, runner trust, and action pinning, because those are common places where poisoned context turns into real system change.

Risk and Threat Considerations

Action poisoning is risky because the attacker is not always trying to break the model, they are trying to steer its execution path. A poisoned action chain can create silent data loss, unauthorized changes, or repeated abuse if the corrupted state survives across steps.

Failure mechanism: The attacker injects or alters context, memory, or tool outputs so the agent treats a harmful action as trusted workflow state and executes it with legitimate privileges.

Impact: This can produce unauthorized tool use, record tampering, data exfiltration, or persistent compromise of an automation flow, often without an obvious single malicious command.

Practitioner Guidance

Why practitioners should care: Action poisoning is a governance problem because the real failure is delegated authority being exercised on attacker-shaped instructions. Teams should define which actions are reversible, which require human approval, and which must be blocked unless the provenance of the instruction is trustworthy.

What to watch for: Review for suspicious action sequences, unexpected state changes, tool calls that do not match the user’s intent, and repeated execution of commands derived from older or external context. Those are often the clearest signs that the agent has been steered rather than simply mistaken.

Related resources from NHI Mgmt Group

• GitHub Action Tag Poisoning
• What is agent communication poisoning?
• What is the 'no prompt means no action' principle in Agentic AI security?
• When should organisations require human approval for an AI agent action?