AgentECC: Repairing Hijacked Agent Actions Wherever the Environment Keeps a Witness

Tool-using agents act on data they do not control. A line planted in an email or a file can redirect a payment while the rest of the task runs as asked. An execution guard can refuse the call, but stopping the payment does not recover its intended payee. A person may have to finish the task, and that handoff cost is much of why agents are not left to run unattended. We treat the injected value as corrupted data, with two recovery paths. When an independent, protected record determines the value the authorized action needs, the guard restores it without human involvement. When no record determines it, one scoped question about that field can obtain the missing value from an authorized source. AgentECC is a runtime guard with both responses, refusing when neither is available. Before deployment, an agent reads each tool's schema and writes a contract naming which arguments carry consequences and which trusted sources hold their copies; a linter admits or rejects each entry. At runtime a deterministic check compares each guarded argument with those sources, without a model judging safety. We state when each response is sound and measure its environmental coverage before attacks. On AgentDojo's rent tasks, with the same amount-scoped question channel, AgentECC keeps 13 of 20 runs under injection against refusal's 5 on GPT-4o, 14 against 7 on GPT-5.5, and 10 against 1 on Qwen3.5-9B, with no successful attacks in these cohorts. Evaluated adaptive searches find no injection that passes its check. Given the same power to ask about every contested field, refusal still keeps 5 of 20 on GPT-4o, and asks more questions to do it. Refusal need not be the endpoint: a deployment can make more actions recoverable by engineering the records and authorized answer channels their fields need.Preprint, version v1 (manuscript dated 2026-10-05). Landing page with full-text HTML: https://jeremyjc67.github.io/papers/agentecc/