AI Agent Acts on the Wrong Account, Order, or File: Causes and Fixes
The agent resolves an ambiguous or partial identifier to the wrong record and acts on the wrong account, order, file, or user.
11 patterns in this category
AI agents most often fail at external actions not in deciding what to do, but in the mechanics of doing it safely — acting without authorization, hitting the wrong target, firing the same action twice, or executing an action with no way to undo it. External-action failures matter more than most because external actions are the point where an agent stops reasoning internally and starts changing the state of a real system — a payment processor, a production deployment, a customer’s account — where the consequences of a mistake exist independently of whatever reasoning produced the mistake.
| Goal | Covers | Patterns |
|---|---|---|
| Action Execution | Authorization, targeting, execution integrity, and containment when an agent acts on external systems | 11 |
Total: 11 patterns
External actions is currently a single-goal category, so there’s no internal pipeline to describe — Action Execution covers the full arc from whether an action is authorized at all, through whether it’s aimed at the right target and fires cleanly exactly once, to whether its consequences can be contained or undone. If a debugging session narrows to “the agent’s decision was right but something went wrong when it acted on it,” Action Execution is the goal to check, and which pattern applies depends on which part of that arc broke: authorization, execution mechanics, targeting/timing, or rollback/containment.
A domain-decision failure means the agent chose the wrong course of action given the facts (e.g., approving a refund a policy doesn’t allow). An action-execution failure means the agent’s chosen course of action was correct, but something broke in carrying it out — it hit the wrong target, fired twice, or executed with no rollback path. Policy-violating-action sits at the boundary: the decision to violate policy and the act of violating it happen in the same step. See Domain Expertise.
No. Every pattern’s Prevention section relies on infrastructure the model doesn’t control directly — idempotency keys, capability tokens, policy engines, target-confirmation UIs, rollback registries — because action-execution failures are zero-tolerance failure modes where the fix has to be enforced by a gateway the agent cannot bypass, not by hoping the model reasons its way to the right call every time.
Start with what went wrong: if the agent shouldn’t have been able to act at all, check unauthorized-action or policy-violating-action; if the action itself misfired, check duplicate-action, partial-execution, or unbounded-action-loop; if it hit the wrong entity or branch, check wrong-target-action, wrong-workflow-branch, or premature-action; if the aftermath couldn’t be contained, check insufficient-rollback or external-side-effect-surprise.
The agent resolves an ambiguous or partial identifier to the wrong record and acts on the wrong account, order, file, or user.
The agent retries a write-type tool call after a timeout or ambiguous error and ends up creating duplicate tickets, emails, orders, or charges.
The agent executes a delete, send, payment, or deployment without approval, because the action carries no reversibility classification requiring a confirmation gate.
The agent performs an action no one actually authorized, because its service credentials are over-scoped and no runtime check confirms the action matches the session's authorization.
The agent gets stuck retrying the same failing action with no retry cap, backoff, or action budget, until quota, cost, or damage accumulates.
Agent misses that action triggers notifications, billing, shipment, or deployment.
Agent cannot undo a bad action.
Agent completes only some steps but reports full success.
Agent does technically possible but disallowed action.
Agent acts before enough evidence is gathered.
Agent chooses refund vs replacement, escalation vs resolution incorrectly.