Honeypots Are the Numbers That End Your Campaign

The prevailing story about dialer reputation is that it is a caller ID problem. Buy cleaner DIDs, attest them properly, warm them gently, and the "Spam Likely" labels stay away. That story is half right, and the half it gets wrong is the half that kills campaigns.

The quiet killer is the honeypot. A honeypot, or spam trap, is a phone number planted specifically to catch dialers. Nobody lives there. No customer opted in there. It exists so that when your dialer calls it, a machine records the event, and carriers and analytics engines treat that single event as strong evidence your list is scraped, dirty, or both. Hit one and your caller ID reputation burns regardless of attestation, regardless of branded CNAM, regardless of how carefully you warmed the number. You can have a perfectly attested DID with a clean B-ring and still get labeled, because the label is algorithmic and the algorithms weight honeypot hits heavily.

Honeypots are a fraction of a percent of answered calls. A single hit carries outsized weight. That asymmetry is the whole problem, and it is why I treat honeypot handling as a first-class AMD concern rather than a list-hygiene afterthought.

What a honeypot actually is

Three flavors matter operationally, because they get onto your list in different ways and call for different fixes.

A pure trap is a number that was never assigned to a real subscriber. It sits in blocks owned or monitored by analytics providers, litigators, and enforcement bodies. It appears on no legitimate list. If it is on your dialer, you scraped something, bought something, or generated something you should not have.

A recycled trap is a number that used to belong to a person, was surrendered, and was repurposed as a trap after a quarantine period. Old opt-in data goes stale; the number that once said yes now says "gotcha." These hit shops that dial aged lists without re-verification more than they would like to admit.

A litigator trap is a number operated to record unsolicited calls and build evidence rather than to filter spam. It answers like a person. It may even engage briefly. Its job is to capture your caller ID, your agent's opening line, and your campaign identity for a TCPA file. The FTC's Telemarketing Sales Rule is enforced on exactly this kind of recorded evidence, and the rule's abandonment limit under 16 CFR 310.4(b)(4), 3% of calls abandoned per campaign, measured over 30 days, is the companion statute that trap operators build cases around.

Why your AMD is the thing that walks you into the trap

Here is the part the industry gets wrong. Shops treat honeypots as a list problem, full stop. They are also an AMD problem, for two reasons.

First, stock AMD cannot see a trap. Asterisk app_amd outputs two useful buckets: HUMAN or MACHINE, plus NOTSURE when the timing heuristic gives up. It has no concept of a spam trap, so a honeypot that answers with a short "hello" is classified HUMAN. Your dialer connects an agent. The agent speaks. The trap records. Now you have generated not just a dial event but a documented agent conversation with a number nobody consented to. From the litigator's perspective, that is a better exhibit than a bare missed call.

Second, bad AMD behavior at a honeypot looks like abuse, because it is statistically indistinguishable from abuse. The analytics engines that attach spam labels watch signals: dial volume per DID, answer rate, talk-time ratio, short-duration call concentration, and honeypot hits. Default app_amd tuning drops an estimated 10-20% of live humans, we measured that. Those dropped humans are sub-five-second calls. A honeypot that your AMD misjudges as a machine gets a dead-air call, or a misfired voicemail drop. From the outside, that pattern, repeated short silent calls to a number that reports dialers, is precisely the fingerprint the engines were built to penalize. Your range gets toast-ed not because any human complained, but because your detection stack produced the wrong audio at the wrong number.

The defaults make it worse. Stock app_amd ships with total_analysis_time at 5000ms, initial_silence at 2500ms, and greeting at 1500ms. That means the heuristic will happily sit on a trap for five full seconds, drop a message or dead air, and move on. Multiply by redials, because traps never opt out, and one stale list segment can hammer a single trap dozens of times before anyone looks at the per-number stats. Honeypots never complain. That is their design. The first visible symptom is your answer rate collapsing across the whole range.

The classification problem timing cannot solve

Recognizing a honeypot is not a timing problem. It is a classification problem. A trap answers like a person, often a crisp, short greeting engineered to trigger a HUMAN verdict and an agent connect. Timing heuristics measure silence durations and word lengths against thresholds, so a well-crafted trap greeting lands squarely in the HUMAN bucket. There is no amd.conf setting that separates it from your best lead, because the discrimination has to happen on what the audio is, not how long the pauses are.

That is why acoustic classification is the right tool here. AMDY runs an AI model over the answer audio itself and returns more than two buckets: human, machine, voicemail, carrier false answer, fax, silence, and a distinct honeypot class. Detection starts at 1/8 of a second (125ms) at 99% accuracy, so the verdict arrives before your agent bridge completes, not after five seconds of threshold arithmetic. When the model flags a honeypot, you drop the call silently and suppress the number, which is the only correct response: no agent audio, no message deposit, no repeat dials.

This matters for the 3% abandonment math too. Every trap call your dialer counts as answered-and-dropped lands in your abandonment denominator behavior. Under the TSR, 3% per campaign per 30 days is the ceiling, and it is a per-campaign measure, not a portfolio average. Traps and the dead-air calls they induce are pure downside: no revenue, no contactable human, all risk. We cover the abandonment mechanics in the TCPA 3% rule in practice and predictive dialer abandonment rates.

Honeypot types, triggers, and fixes

No invented percentages here. If you want to know your own exposure, the measurement method is: pull your per-detection log, count detections carrying the honeypot class per campaign and per list, and divide by answered calls on the same slice. Anything above zero warrants a list-source audit, because pure traps should never appear on a legitimately sourced list.

Honeypot type	What triggers it	Operational fix
Pure trap	Number was never a subscriber; enters your list via scraped, purchased, or randomly generated data	Suppress on detection; audit the list source that produced it; stop dialing that source segment
Recycled trap	Former subscriber number repurposed after quarantine; aged opt-in data goes stale	Re-verify opt-in age before dialing; suppress on detection; shrink re-dial windows on old lists
Litigator trap	Answers like a person to capture agent audio and caller ID for a TCPA file	Drop on detection before agent bridge; suppress the number range-wide; log the event for your compliance record

The suppression step is not optional. A honeypot class on one detection should poison that number across every campaign on the box, because the trap does not care which campaign redials it. This is also where a queryable detection log earns its keep: you need per-number, per-campaign export to prove to yourself (and, eventually, to a carrier or a regulator) what you dialed, what you detected, and what you did about it.

Detection is cause removal, not an eraser

I want to be precise about what honeypot detection does and does not do, because this space is full of magic-eraser claims. No tool lifts a spam label that is already attached. Labels lift over time as your behavior cleans up. What detection does is stop you feeding the engines that flag you: no more agent conversations with traps, no more dead-air signatures, no more voicemail drops into numbers that exist to record them. It removes the cause. DID rotation, warming, branded caller ID, and per-number answer-rate monitoring are still your job, and they work better once the trap traffic is gone. The full pipeline, how flags attach and how they lift, is covered in how outbound call centers get flagged and spam flags, ghost calls, and caller ID.

Two operational habits to pair with detection:

1. Watch per-number, not per-campaign

Trap damage concentrates. A campaign-level answer-rate dashboard can look healthy while one list segment hammers three traps into oblivion. Your detection log export should let you sort by honeypot count per called number and per DID, and you should look at it weekly during any list change.

2. Treat a honeypot hit as a list-provenance event

A pure trap on your dialer means bad data got in. Detection tells you which call; only list lineage tells you how. Log the list ID, the vendor, and the ingestion date alongside every honeypot suppression, or you will buy the same dirty segment again next quarter.

How one hit propagates

It helps to understand the plumbing, because the speed of propagation is why operators get blindsided. Your dial places a call to a trap. The trap's operator logs the event, caller ID, timestamp, call duration, and, if an agent spoke, a recording. From there the signal fans out. Analytics providers that power carrier-level spam labeling consume trap reports as a high-confidence input. Carriers run their own spam databases and share reputation data across the intercarrier feeds that decide whether your call reaches a handset labeled, unlabeled, or blocked by default on Android and iOS silencing. A single trap hit is weighted far above a single subscriber complaint, because a complaint can be a wrong number or a grudge, while a trap hit can only mean your dialer called a number that was never contactable.

The asymmetry compounds across your range. Analytics engines score per number, but they also score number blocks. Dial enough traps from enough DIDs in the same block and the block itself acquires a reputation deficit that your next fresh DID purchase inherits. This is why "we just rotated to new numbers" fails as a remediation strategy when trap traffic is still flowing: you are pouring the same contaminant into cleaner glassware.

There is no appeals board for this. Reputation lifts behaviorally, which means the only durable remediation is to change the behavior, starting with stopping the trap traffic at the moment of detection.

Redials: the multiplier nobody budgets

One trap on a list is not one call. Unanswered or short calls feed a dialer's recycle logic, and traps are engineered to produce exactly the call profile that triggers re-dials: answered, brief, no disposition. A recycle setting of a few attempts per number over a few days, routine for lead-gen lists, converts one stale number into a repeated pattern of short silent calls. Each attempt is another logged event for the trap operator and another short-duration call in your per-DID stats.

Suppression on first detection is therefore worth more than any downstream hygiene. If your detection stack flags a honeypot on attempt one, your exposure from that number is one event instead of a campaign-length pattern. That difference, one row versus a histogram, is the difference between a reputation blip and a label.

List hygiene cadence that actually matters

Detection without list discipline is a treadmill. The cadence I recommend, in order of leverage:

On ingestion

Before a new list segment dials, check it against your own suppressed-number set, which should include every honeypot ever detected on your traffic. Your historical detections are the only trap data you own outright. Everything else you are renting from someone else's reputation feed.

On first detection

Suppress the number range-wide immediately, tag the list ID, and freeze the segment if the same segment produces more than one trap in a short window. Two traps from one vendor's segment is not a coincidence; it is a data-provenance statement.

Monthly

Export the honeypot class counts per list source and per campaign. Trend them. A source that was clean two quarters ago can go dirty through list decay and recycling on the vendor side, and the monthly trend catches it before the analytics engines do.

A note on scope and honesty

Be skeptical of anyone selling a honeypot solution as a solved problem. Traps evolve; operators rotate numbers; recycled traps appear in data that was legitimately sourced years ago. What a detection layer owes you is not a promise of zero traps. It is a distinct class label at the moment of answer, a silent drop before your agent or message touches the line, a queryable log of every event, and the reporting to see your own trend. That is the whole honest scope, and it is enough: enough to stop feeding the engines, enough to audit your data provenance, enough to keep a clean range clean.

The FTC maintains resources on robocall enforcement and the rules the trap evidence feeds into; the TSR abandonment provision at 16 CFR 310.4 is the one to read alongside your own counsel, because it defines the per-campaign measurement a litigator will try to construct from your trap interactions.

Where this sits in the stack

Honeypot detection is one layer of the AMD surface, not a bolt-on. On our side it ships with the rest of the classification set: per-carrier FAS breakdown (false answer supervision is its own silent killer, carrier false answers run roughly 14% of "answered" calls on our network, and they present as silence to a timing heuristic), recording review with classification, real-time dashboards per IP, per server, and per carrier, and a compliance audit log built to TCPA and HIPAA-ready standards. The features page has the full list.

Pricing does not gate it behind an enterprise tier. Sandbox is $0 with a 50,000-detection hard cap, Starter is $79 for 500K detections then $0.00025 each, Growth is $299 for 5M then $0.00015, and Scale is $999 for 25M then $0.00010. Every plan runs unlimited servers, because charging per server on a detection product is a tax on infrastructure choices, not on value. If you want to quantify your trap exposure before spending anything, run your existing traffic through Sandbox and count the honeypot class hits. That number, your number, not an industry average, is the honest basis for the decision.

The takeaway

Caller ID reputation is downstream of call behavior, and the highest-weight behavior signal a dialer can produce is a honeypot hit. Attestation does not launder it, warming does not offset it, and stock AMD cannot even see it. Detect the traps, suppress the numbers, audit the list source, and the reputation problem shrinks to something DID hygiene can actually manage.

Or, as a question to the operators reading this: when you last audited your per-number detection log, what was the oldest un-suppressed number that had answered more than five of your calls? In my experience, that is where the trap lives.