Our agent approved a $2,400 fraud refund in 30 seconds

Last week our support agent approved a $2,400 refund for what turned out to be a sophisticated fraud attempt. The customer claimed our API was "randomly failing" and provided logs that looked legitimate. Our agent, trained to be helpful, saw the complaint and issued the refund immediately.

The logs were fabricated. The API calls never happened.

This wasn't a prompt injection or a clever social engineering attack. It was something more fundamental: our agent had no way to verify claims against reality. It could read the fake logs, but it couldn't check our actual API logs to see if those requests ever existed.

We built what we're calling "reality anchors" — verification checkpoints that force the agent to cross-reference customer claims with actual system data before taking expensive actions.

Here's the pattern:

BEFORE ISSUING REFUND:
1. Extract API request IDs from customer complaint
2. Query actual API logs for those request IDs  
3. If no matching requests found → escalate to human
4. If requests found but succeeded → escalate to human
5. Only if requests found AND failed → proceed with refund

The key insight: customer-provided evidence gets verified against source-of-truth systems before any financial action.

We implemented this as a pre-action hook in our agent's refund workflow. Every refund request now triggers a mandatory verification step that queries our actual API logs, payment records, and error monitoring systems.

The fraud attempt that cost us $2,400 would have been caught in step 2 — zero matching API requests in our logs.

This pattern works for any high-stakes agent decision:

• Support refunds: Verify error logs against actual system logs
• Account changes: Verify user identity against authentication records
• Billing disputes: Verify transaction claims against payment processor records
• Service issues: Verify outage reports against monitoring dashboards

The implementation is straightforward — we added verification functions that our agent must call before executing any financial action. The agent can't skip these steps; they're built into the workflow as mandatory checkpoints.

Since implementing reality anchors three weeks ago, we've caught four more fraud attempts and prevented two legitimate refunds that would have been issued for user error (not system failure). Our false positive rate for refunds dropped from 23% to 3%.

The pattern costs us about 2-3 extra API calls per support case, but saves us thousands in fraudulent refunds and hours in manual review.

Your agents need reality anchors before they need more autonomy. Customer claims should never be the only source of truth for expensive decisions.