Agentic Flooding: How Bots DDoS Government Services and How to Detect Them

The Siege: What Agentic Flooding Looks Like

Government digital services are crumbling under a new class of attack. Not the volumetric DDoS you’re used to—no SYN floods, no amplified UDP reflection. This is agentic flooding: autonomous LLM-powered bots that navigate complex web forms, book appointments, file FOIA requests, and submit public comments at a scale and sophistication that mimics genuine human interaction.

A recent paper from the University of Chicago’s SAND Lab and collaborators (source: arxiv.org/abs/2608.16603) provides the first systematic characterization of this threat. The researchers built a controlled testbed simulating a municipal benefits portal and unleashed agentic bots against it. The results are sobering. A single $20 API key can generate thousands of realistic, contextually appropriate submissions that bypass traditional CAPTCHAs and rate limiters. These aren’t script-kiddie cURL loops. They’re goal-directed agents that reason about form fields, handle errors, retry with backoff, and even solve visual challenges using vision-language models.

The study documents three real-world incidents that already map to this pattern: a coordinated FOIA request flood that paralyzed a county clerk’s office, a public comment period hijacked by generated submissions indistinguishable from constituent letters, and a benefits portal where appointment slots were scraped and hoarded by reseller bots within seconds of release.

This is no longer theoretical. The attack surface is live, and the asymmetry is brutal: attackers wield commodity LLM APIs, while defenders rely on brittle heuristics designed for a pre-agentic internet.

Why FDEs and Platform Engineers Should Care

If you’re a Forward Deployed Engineer or a platform engineer working on civic tech, this is your problem now. The old playbook—rate limiting by IP, session-based CAPTCHAs, form honeypots—fails against agents that rotate residential proxies, maintain stateful sessions, and solve CAPTCHAs via services like 2Captcha or multimodal models.

Here’s the engineering reality: agentic flooding exploits the semantic gap between what a form intends and what a bot can infer. A traditional bot fills fields with garbage. An agentic bot fills them with coherent, on-topic text that passes superficial review. The paper shows that GPT-4o-generated public comments were rated by human reviewers as more persuasive than genuine citizen submissions in blind tests.

For FDEs embedding with government customers, this translates directly to trust erosion. When a city’s affordable housing waitlist gets flooded with 10,000 AI-generated applications, the system doesn’t just slow down—it becomes legally and operationally compromised. The waitlist loses legitimacy. Staff spend weeks triaging synthetic applicants. The most vulnerable users, who can’t compete with bots for appointment slots, get locked out entirely.

This is the kind of problem FDEs are built to solve. It sits at the intersection of infrastructure hardening, ML detection, and customer-facing trust restoration. If you’ve ever shipped a /blog/the-fde-toolkit-data-integrations-demos for a public-sector deployment, you already have the integration chops. Now you need the detection logic.

The Attacker’s Playbook: Recursive Autonomy

To detect agentic flooding, you need to understand the attacker’s architecture. The paper models it as a three-layer stack:

1. Orchestration Layer: A controller agent (often LangChain or AutoGPT-style) that parses a high-level goal (“book all available DMV appointments for resale”) and decomposes it into subtasks.
2. Interaction Layer: A browser automation framework (Playwright, Puppeteer, or Selenium) driven by an LLM that observes the DOM, reasons about form semantics, and generates appropriate inputs. This layer handles JavaScript rendering, session cookies, and redirect chains—exactly like a real browser.
3. Evasion Layer: Proxy rotation (residential IP pools via BrightData or similar), CAPTCHA-solving APIs, randomized inter-request delays drawn from human-like distributions, and browser fingerprint randomization (canvas, WebGL, font enumeration).

The key insight from the paper: these layers operate with recursive error recovery. If a form submission fails validation, the agent reads the error message, adjusts its input, and retries. If a CAPTCHA appears, it routes the challenge to a solving service. If the site imposes a cooldown, the agent persists state and resumes later. This isn’t a script; it’s a persistent, adaptive adversary.

Detection Engineering: Signals in the Noise

The paper proposes a detection taxonomy that moves beyond IP reputation. The most actionable signals for engineers:

Temporal Micro-Patterns: Humans exhibit chaotic inter-event timing. Bots, even with jitter, produce timing distributions that are too uniform. The researchers measured keystroke-to-keystroke intervals and mouse movement trajectories. Agentic bots show unnaturally smooth cursor paths (Bézier curve interpolation) and keystroke latencies with lower variance than human baselines.

Semantic Fingerprinting: LLM-generated text has measurable statistical signatures. The paper uses a combination of perplexity scoring, burstiness analysis, and embedding-space density. Generated text tends to have lower perplexity (it’s too “clean”) and higher semantic similarity across submissions from the same campaign. If 500 public comments all cluster within a cosine similarity of 0.92 in an embedding space, you’re looking at a template with minor variations—not 500 independent humans.

Behavioral Consistency: Agents reuse interaction patterns. The sequence of DOM events (focus, input, blur, scroll) forms a behavioral fingerprint. The paper found that agentic bots exhibit significantly lower entropy in their event sequences compared to humans, who are messy and inconsistent.

Resource Exhaustion Patterns: Unlike volumetric attacks, agentic flooding targets logical resources: appointment slots, application queue positions, review workflows. The attack signature is a sudden spike in successful form completions—not failed attempts. Traditional WAFs miss this because every request looks legitimate.

Architecture: A Real-Time Detection Pipeline

Here’s a production-grade detection architecture you can pitch to a government customer. It operates at three levels:

Edge Layer (CDN/WAF): Deploy JavaScript challenge injection that collects client-side telemetry: mouse movement entropy, keystroke timing distributions, and browser fingerprint consistency. Ship this data as a side-channel to your detection service. This doesn’t block the user; it observes them.

Application Layer: Instrument your form handlers to emit structured event logs. Every focus, input, blur, scroll, and submit event gets timestamped and attributed to a session. Compute rolling entropy scores on event sequences. When a session’s behavioral entropy drops below a threshold calibrated on human baselines, flag it.

Analytics Layer: Run batch embedding analysis on submitted text. For public comment portals or application forms, compute pairwise cosine similarity across recent submissions. Cluster them. If a cluster exceeds a size threshold and its centroid has low perplexity, trigger an alert for manual review.

Try It Today: A Minimal Viable Detector

You don’t need a government contract to start experimenting. Here’s a weekend project that captures the core detection logic:

1. Stand up a simple form—a Flask or FastAPI app with a textarea and a submit button. Make it look like a public comment form.
2. Instrument client-side telemetry with a small JavaScript snippet that records mousemove, keydown/keyup timestamps, and focus/blur events. Ship this as a JSON blob on submit.
3. Build the attacker: Use Playwright with the OpenAI API. Write a short script that navigates to your form, fills the textarea with a GPT-4o-generated comment on a fixed topic, and submits. Run it 200 times with varying prompts and delays.
4. Run the detector: On the server side, compute two metrics per submission:
   • Keystroke latency variance: Human typists have high variance; bots with page.fill() have near-zero variance.
   • Text perplexity: Use a small language model (GPT-2 is sufficient) to score the generated text. Low perplexity = likely synthetic.
5. Set thresholds: Plot the distributions of both metrics across your 200 bot submissions and 50 genuine human submissions (ask friends or use Mechanical Turk). Find a decision boundary.

This exercise teaches you the fundamental asymmetry: generating the attack is trivial; detecting it requires modeling human behavior. If you want to go deeper on building agents that interact with real systems, our guide on building a /blog/sql-analyst-agent-postgres-free-llm walks through the orchestration patterns.

The Countermeasures Debate: A Balanced Take

The paper is clear-eyed about the limits of detection. The authors argue that purely technical countermeasures create an arms race where attackers adapt faster than defenders can patch. Their recommendation: process-level defenses that change the economics of the attack.

Examples they cite:

• Identity proofing: Require identity verification (e.g., Login.gov, ID.me) before accessing scarce resources like appointment slots. This doesn’t stop bots, but it caps the number of unique identities an attacker can mobilize.
• Cost imposition: Small, refundable deposits for high-value actions. A $1 hold on a credit card to book a DMV appointment eliminates bulk hoarding.
• Asynchronous verification: For public comments, send a physical mailer with a verification code to the submitted address. This doesn’t scale for attackers.

However, these introduce friction that disproportionately affects legitimate users who lack digital literacy, credit cards, or stable addresses. The equity trade-off is real. An FDE’s job is to surface these trade-offs clearly: “Here’s what pure detection can catch, here’s the false-positive rate, here’s the process change, and here’s who gets locked out.”

There’s a parallel here to the broader challenge of AI reliance eroding core skills—a pattern we’ve explored in the context of /blog/ai-coding-collapse-expertise-mitigation. When detection systems become too aggressive, human operators over-trust the automation and stop investigating edge cases. The same dynamic applies: you need human-in-the-loop review for flagged submissions, and you need to continuously recalibrate thresholds as attacker behavior evolves.

FAQ

Is this really different from a botnet filling forms? Yes. Traditional botnets use scripted, deterministic interactions. Agentic flooding uses LLMs to reason about each form field, adapt to validation errors, and generate contextually appropriate content. It’s the difference between a battering ram and a lockpick.

Can’t we just use better CAPTCHAs? The paper shows that multimodal models (GPT-4o, Claude 3.5) solve reCAPTCHA v2 with >95% accuracy when combined with browser automation. Audio challenges are even easier. CAPTCHAs are a speed bump, not a wall.

What’s the first thing I should instrument on a government form? Client-side event telemetry. Start capturing keystroke timings and mouse trajectories. Even without a full detection pipeline, having this data lets you retroactively analyze an attack and build baselines. It’s cheap to implement and hard for attackers to perfectly emulate at scale.

Does this apply to non-government services? Absolutely. Any service with scarce digital resources—appointment booking, limited-edition product drops, ticket sales, job application portals—is vulnerable. The detection patterns generalize.

How do I convince a government client this is worth funding? Quantify the cost of inaction. The paper documents a county where 70% of FOIA requests in a quarter were agentic, costing an estimated $180,000 in staff time. Frame the investment as operational risk reduction with a measurable ROI. FDEs who can build this business case—combining technical detection with financial modeling—are the ones who shape /blog/post-sale-fde-product-engineering-collaboration outcomes.