If an AI agent can't be tricked into new actions, could it still be tricked into sending money to the wrong address?

This explores whether locking down an agent's sequence of actions is enough, or whether attackers can still win by changing the data those actions run on. The corpus suggests the gap is real, and that the strongest defenses are the ones built to close it. The starting point is a set of architectural patterns, such as Action-Selector and Plan-Then-Execute, that resist prompt injection by cutting the path from untrusted input to consequential actions Can structural design patterns block prompt injection attacks?. If the agent commits to a plan before it reads any untrusted email or web page, injected text can't add a new step. These are real guarantees, not probabilistic filters. But a fixed plan can still have holes in it. If the plan says "read the document, then send a summary to the address it mentions," an attacker doesn't need to change the plan. They only need to change the address.

CaMeL is the clearest answer to that problem in the collection Can capability tracking stop prompt injection attacks?. It separates control flow from data flow and attaches metadata to every value in the agent's execution, recording where the value came from and where it's allowed to go. A policy can then block untrusted data from reaching sensitive tool arguments, even when the action itself was legitimately planned. That protection has a measurable cost. CaMeL solved 77% of AgentDojo tasks, 7 points below an undefended agent, in exchange for guaranteed policy compliance. Progent takes a related approach Can an SMT solver prevent LLM policy drift during agent execution?. A formal solver, not the LLM, decides whether each permission change narrows or widens what the agent can do. This blocks a quiet form of data attack, where manipulated input slowly loosens the rules.

Looking more broadly, the same weakness shows up wherever a defense checks pieces in isolation. Stateless guardrails can't express rules that depend on what happened earlier, so a series of individually allowed actions can add up to a violation Can stateless checks ever catch sequence-level constraint violations?. Skill scanners that score each skill separately can be evaded: attackers use scanner feedback to make each piece look harmless while the chain as a whole stays malicious, reaching 96% attack success Can attackers evade skill scanners by refining individual skills?. SafeFlow responds by validating the assembled workflow right before any irreversible action, at the point where the full risk picture finally exists Where should workflow validation gates be placed for safety?.

The less obvious lesson is that the data an attacker targets isn't always the user's content. Routing metadata, which decides which model handles a request, sits below prompt-level defenses and can be manipulated to send requests to weaker models or attach safety checks to the wrong identity Can attackers manipulate which model handles a request?. Encrypted reasoning blocks are passed back and forth as opaque values, and it turns out they're interchangeable across models from the same provider. A weaker model can decode a stronger model's hidden reasoning verbatim Can cheaper models decrypt traces from stronger models?. In both cases the system's control logic worked as designed. The attack succeeded because a value was trusted without checking where it came from. So the answer is yes: securing control flow is necessary but not sufficient, and the defenses that hold up also track where each piece of data came from and where it is allowed to go.