11 patterns for this issue
The agent retries a write-type tool call after a timeout or ambiguous error and ends up creating duplicate tickets, emails, orders, or charges.
AI agent's action unexpectedly triggers notifications, billing charges, shipments, or deployments it never intended to cause.
AI agent executes a destructive action with no way to roll it back or undo it afterward.
The agent executes a delete, send, payment, or deployment without approval, because the action carries no reversibility classification requiring a confirmation gate.
AI agent completes only some steps of a multi-step task but reports full success to the user.
AI agent performs an action its tool permissions allow but that violates business or regulatory policy.
AI agent takes an irreversible action, like banning a user or closing a case, before enough evidence is in.
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.
The agent resolves an ambiguous or partial identifier to the wrong record and acts on the wrong account, order, file, or user.
AI agent chooses the wrong path in a decision workflow — refund vs. replacement, escalation vs. resolution — based on surface pattern-matching instead of the applicable rule.
Action-execution failures happen when an agent’s decision to act is correct but the act itself — its authorization, target, timing, or mechanics — is not, so the agent ends up charging the wrong account, deleting something it can’t restore, or looping a retry into a runaway cost. Action-execution failures matter more than most because the failures are the point where an agent stops reasoning and starts changing the state of a real external system — a payment processor, a ticketing system, a production deployment — where mistakes carry their own blast radius independent of whatever reasoning produced the mistake.
All 11 action-execution patterns converge on the same architectural answer: separate “technically able to call this API” from “authorized and safe to call this API right now,” and enforce that separation with a gateway the agent cannot bypass. Concretely, that means idempotency keys and state-transition guards for execution integrity, capability tokens and policy engines for authorization, target-confirmation summaries and evidence-threshold gates for targeting and timing, and pre-declared rollback/compensation plans plus side-effect manifests for containment. The common thread in every Detection & Response section is also structural: don’t trust the agent’s own success report — reconcile the actual state of the external system (audit trail divergence, state integrity checks, resource orphaning detection) against what the agent claims it did, because an agent that got the action wrong will often still report success.
Unauthorized-action means the agent lacks permission for the action or target resource at all — an identity/capability failure caught by a capability token or namespace check. Policy-violating-action means the agent has generic permission to perform that action type, but the specific instance breaks a business rule (e.g., a refund policy’s dollar cap or time window) — caught by a policy engine evaluating the action’s parameters, not just its identity.
Wrong-target-action is the right action taken against the wrong entity — refunding the wrong customer’s order. Wrong-workflow-branch is the right entity but the wrong action type chosen for it — issuing a refund when a replacement was the correct branch. Both are targeting/decision failures, but one is about “who,” the other about “which path.”
No. The duplicate-action mitigation pairs idempotency keys with state-transition guards and audit-trail divergence monitoring, because idempotency keys only catch a retry that reuses the same key — they don’t catch two independently-initiated requests for the same real-world outcome, which requires comparing the intended action against the actual system-state delta.
Irreversible-action-without-confirmation is explicitly built around mandatory human confirmation before execution. Insufficient-rollback and no-rollback-plan-adjacent patterns route to human approval whenever an action is classified as irreversible with no defined compensation. Premature-action and policy-violating-action both route to expert-in-the-loop review when evidence or policy checks fail.
| Pattern | Mechanism |
|---|---|
| Duplicate Action (GitHub) | Agent creates duplicate tickets, emails, orders, or charges |
| External Side-Effect Surprise (GitHub) | Agent misses that an action triggers notifications, billing, shipment, or deployment |
| Insufficient Rollback (GitHub) | Agent cannot undo a bad action once executed |
| Irreversible Action Without Confirmation (GitHub) | Agent deletes, sends, pays, or deploys without required approval |
| Partial Execution (GitHub) | Agent completes only some steps of a multi-step action but reports full success |
| Policy-Violating Action (GitHub) | Agent performs a technically possible but disallowed action |
| Premature Action (GitHub) | Agent acts before enough evidence is gathered |
| Unauthorized Action (GitHub) | Agent performs an action without permission |
| Unbounded Action Loop (GitHub) | Agent repeats an action until quota, cost, or damage accumulates |
| Wrong Target Action (GitHub) | Agent acts on the wrong account, order, file, or user |
| Wrong Workflow Branch (GitHub) | Agent chooses the wrong branch — refund vs. replacement, escalation vs. resolution |
Total: 11 patterns