The $5,000 AI-minute drain attack (and the one setting that stops it)

You wake up on a Tuesday to a billing alert from your AI voice vendor. Your monthly minute allowance — the one you'd sized at generous headroom — is at 94% before 7 a.m. Your actual customers haven't been awake for an hour. Somebody else has been using your AI.

Welcome to the AI-minute drain attack. It's the simplest and most-ignored abuse pattern in the voice-AI space, and almost every voice-platform ships without a mitigation for it on by default.

How the attack works

Someone — a bored kid, a competitor's intern, a stress-test script that forgot to stop, a toll-fraud ring looking for easy targets — finds your public phone number. They dial it. Your IVR answers. The AI vendor spins up a session, generates a greeting, waits for the caller to speak. The caller hangs up two seconds into the greeting. Session over.

That cost you two things:

• The platform minute on your voice-provider account — a connected minute is a connected minute whether the caller stayed for the whole conversation or hung up on the first word.
• The AI vendor session — most AI voice vendors charge by the minute-of-connected-audio, with a minimum session cost. ElevenLabs, Vapi, Retell, and the realtime APIs all behave the same way: you pay for the hello.

Now imagine the caller does that in a loop. 200ms between redials on a decent connection. That's roughly 300 call sessions per minute, each billed as a minute by your AI vendor (minimum session rounding). Overnight that's 180,000 billable sessions. At ElevenLabs pricing of roughly $0.11/min (Conversational AI), that's $19,800 in a single night. Even the biggest plan allowances crumble under this.

Why rate-limiting at the AI vendor doesn't help

AI voice vendors don't know who's calling. They receive a session request from your voice platform; they can't tell whether the originating caller is one person dialing 300 times or 300 people dialing once each. Any throttle they expose is per-API-key — i.e. per-you, not per-caller — so turning it on would just rate-limit your own real traffic.

The throttle has to happen one layer up, at the voice platform that answers the call, before an AI session is ever spun up.

The setting that stops it

Every Voylo-hosted number has a per-caller rate limit, off by default (because real traffic should never trip it) but turnable on in two clicks. It's a sliding 60-second window, counted per caller-E.164 per DID. Exceeds the cap, we hang up with SIP cause 34 (congestion) and tag that caller for a block window of your choosing — the next N minutes of attempts from the same caller-E.164 get rejected at the SIP layer, before any AI vendor is ever contacted.

Open any number you own, scroll to the Inbound throttle card:

• Max per minute — how many calls a single caller-E.164 can make in a rolling 60-second window. A sane baseline is 5: a frustrated real customer might redial 2–3 times, a scripted attacker burns through 5 in a few seconds.
• Block window — once the cap trips, how long the caller gets rejected before the counter resets. Start at 15minutes. If someone legitimately needs you back on the line, they'll call you back from a different number.

Set both to zero and the gate is off (which is the default for numbers before you touch them).

What a blocked attempt looks like

A throttled call doesn't silently disappear. The CDR shows it as a failed inbound with outcome = "failed" and a rejection reason naming the gate — so the day after an attack you have a precise count of how many you blocked, from which numbers, when. Downstream events (call.rejected, call.ended) still fire so your observability stack sees them.

Your AI vendor was never contacted. Zero session cost, zero platform minutes consumed. Just a one-line entry in your call history and a 486 Busy on the attacker's side.

Why this isn't on by default

It's a question of what's costlier when it goes wrong. Default-off means: the first-time user adds a number, doesn't configure anything, calls land on their AI. That's the most important experience for a new customer. Default-on with any non-trivial cap would block a genuinely enthusiastic caller who redials ten times trying to get a reservation through — a worse outcome than a theoretical attack that hasn't happened to that account yet.

But the moment you're in production serving real customers — the moment a public number is findable— turn it on. A limit of 5/60s doesn't touch any real caller. It makes this specific class of attack cost the attacker time, not you money.

Three mistakes we see

1. Setting the cap too high."20 per minute" feels safe. It's not — a 20-call-per-minute script running for an hour is still 1,200 sessions. Keep the cap low. 5 is plenty for human traffic.
2. Setting the block window too short. If the block expires in 1 minute, the attacker just paces their script at exactly your limit and keeps going. Start at 15 minutes. Attackers move on; honest callers call back from a different phone.
3. Only configuring one number. If you have a fleet of DIDs, apply the throttle to all of them. The attacker will find the one you forgot.

Beyond the per-caller throttle

This gate is one layer in a defense-in-depth setup. Other Voylo features that compose with it:

• Per-number country block list— stops your AI from dialing destinations you didn't authorise (toll fraud's outbound cousin — see our post on outbound country protection).
• Account concurrency cap— your plan's limit on simultaneous active calls. An attacker trying to run 300 parallel sessions hits this ceiling instantly even if the per-caller throttle hasn't.
• Funds gate— if your wallet goes to zero, further outbound auto-pauses. Attacker-induced bills can't compound indefinitely.

The one-line summary

Open your number. Flip Inbound throttle to 5 per minute with a 15-minute block. Save.Thirty seconds of configuration that caps the single most common voice-AI abuse pattern. It's on your Voylo number already — you just have to turn it on.