These aren't hypothetical. They're the patterns we kept seeing when talking to teams shipping AI agents into production — each one a write action that went somewhere it shouldn't have, or said something it shouldn't have said. Every one of them was preventable with a policy checkpoint before the write landed.
A customer support agent was drafting replies to Zendesk tickets. It was performing well — fast, accurate, right tone. On ticket #4,847, a frustrated customer mentioned they'd been waiting three weeks. The agent, optimizing for resolution, replied: "We guarantee a full refund will be processed within 24 hours."
Finance had a different view of what the company could guarantee. Legal had an even different view. The agent sent it before anyone saw it.
block_if_terms: ["refund guaranteed", "full refund"] in the support-reply policy. The agent proposes the reply, Gate scans it, blocks before it reaches Zendesk. Agent sees blockReason: "Payload contains blocked term: refund guaranteed" and routes to a human.A LangGraph pipeline was processing a lead list and writing contacts into Salesforce. It worked correctly in staging — batches of 50, reviewed, approved. In production, someone forgot to set the batch size limit. The agent processed the full file in one shot: 40,211 records, unreviewed, written directly to the CRM at 2:17am.
Duplicates, bad data, and overwritten existing contacts. Monday morning was not great.
auto_approve_under: 100 / require_approval_over: 100. Anything over 100 records goes to the dashboard for human review before a single row writes to Salesforce. The 2am run would have sat in pending until a human approved it — which they wouldn't have, because they would have seen the record count and asked questions.A marketing agent was drafting a campaign email and sending to a filtered segment. The filter logic had a bug — instead of selecting the "re-engagement" segment (800 contacts), it selected all contacts without an unsubscribe flag: 8,231 people. The agent called the email API. The send started before anyone noticed.
8,000 people received an email intended for 800. Unsubscribes spiked. Deliverability took a hit that lasted three months.
recordCount. Policy flags anything over 1,000 recipients for human approval. The agent proposes, Gate holds it pending, a human sees "8,231 recipients" and asks why. Bug surfaces before the send.A billing agent was processing refund requests from a support queue. It matched the refund to a customer by email. Two customers had the same name and similar email addresses — one had an active dispute, one didn't. The agent matched to the wrong record. It called stripe.refunds.create for $1,240 to the wrong account.
The correct customer was still waiting for their refund. The wrong customer got a windfall and didn't mention it. Finance caught it on reconciliation 11 days later.
require_approval: always on the finance-high-risk policy. Every Stripe refund — regardless of amount — goes to human review. A reviewer would have seen the customer name mismatch in the payload before the API call fired.A content pipeline was generating and publishing blog posts to a CMS. It had access to two sites: the company blog and a staging environment. A misconfigured destination variable sent a draft post — internal formatting notes and placeholder copy included — to the live site. It was indexed by Google within 40 minutes.
destinations: [cms.staging] in the draft policy, destinations: [cms.production] in the publish policy — both requiring human approval. An agent pointing at the wrong destination would be blocked immediately with blockReason: "Destination 'cms.production' not in policy allowlist". The misconfiguration surfaces as a Gate block, not a live incident.Every incident above shares the same structure: an agent operating correctly on bad inputs, bad config, or an edge case that fell outside what anyone anticipated. The agent didn't malfunction. It did exactly what it was built to do — and that was the problem.
Agents are fast and consistent. That's their value. It's also their failure mode. A human making the same mistake would have paused, double-checked, noticed the record count was wrong. An agent doesn't hesitate. It executes.
Gate doesn't make agents smarter. It puts a checkpoint between "the agent decided to act" and "the action landed in production" — so the cases where the decision was wrong get caught before they become incidents.
The five policies above are in the Gate repo. Drop them in your policy directory and your agent has guardrails for all five patterns in under 10 minutes.