AI vs. AI: How to Defend E-Commerce from DDoS and Machine-Orchestrated Fraud

The traffic that takes down your store today doesn't come from a 2015 script running in the dark. It comes from a model that generates requests resembling real people, simulates a Black Friday surge on any given Tuesday, and changes shape with every blocking rule you apply. That's the central thesis of the talk "AI vs. AI: The Attack and the Defense Have Already Changed Three Times While You Were Reading This Title", by Rodrigo Jorge, CISO at Strattum, at the Technology & Innovation Plenary of Fórum E-Commerce Brasil 2026 (July 30, 2026, 10:40 am).

The sentence that sums up the problem, according to the talk's official description: "AI has democratized volume. Your store no longer has a risk season. It's the whole year." For those who build and run stores, this reorganizes the logic of security investment: the peak stops being a calendar event and becomes a permanent condition.

The Three Fronts AI Orchestrates at the Same Time

The point that sets today's scenario apart, according to Jorge, isn't a new attack front, but the coordination between them. AI no longer picks a single vector: it runs all three in parallel, adapting within seconds.

| Front | What the Attacker Does | Effect on E-Commerce | |---|---|---| | Availability | "Smart" DDoS with traffic that mimics real users and changes signature with every block | Takes the store offline without triggering classic volume heuristics | | Fraud | Fake pages, synthetic profiles, checkout cloned at scale | Chargebacks, account takeover, and conversion diverted to the attacker | | Code | Continuous probing of the application looking for flaws | Exploiting vulnerabilities before the patch |

The technical detail that matters: a DDoS that "looks like a real user" breaks mitigation based on fixed signatures and volume thresholds. If the bot browses, adds items to the cart, and keeps a human-like pace, the traditional WAF that counts requests per IP can't tell this traffic apart from a real promotion. That's why defense also needs to migrate from static rules to adaptive models.

Defense: AI on the Same Three Fronts

The proposal presented is to mirror the attacker. On the defense side, AI shows up in:

• Adaptive mitigation that absorbs volume and relearns the legitimate traffic pattern instead of relying on fixed blocklists.
• Antifraud that learns, cross-referencing behavioral signals (typing speed, navigation sequence, device reputation) to separate synthetic profiles from real customers.
• Continuous code analysis, probing the application itself before the attacker does.

The caveat the talk makes a point of keeping, and one that usually disappears from vendor pitches, is honest: the machine still gets it wrong, and the human remains the decision-maker. In practice, this means designing the defense pipeline with two different states. An automatic path for what the model classifies with high confidence (blocking or a low-friction challenge, like an invisible challenge) and a human review path for the gray zone, where a false positive costs a legitimate sale. Automating mitigation without this manual escape hatch just trades downtime for checkout friction, which also kills conversion.

The Gap Nobody Puts on the Slide: Internal Risk

The most unusual angle in the talk is what it calls internal risk. While everyone looks at the external attacker, the team itself opens the door from the inside by adopting AI without governance. The three symptoms cited:

• Real code and data exposed in third-party AI tools during development.
• Secrets leaking into production, when API keys and credentials end up in a prompt, log, or repository.
• AI adopted in operations without a policy defining what can and can't leave the company.

This is the point that speaks most directly to the audience that "gets its hands on the code." Adopting AI assistants in the development workflow is now the path of least resistance for leaking sensitive data: a snippet pasted into a chat, an environment variable committed, a database dump used to "test the model." No DDoS mitigation solves this, because the attack surface now includes the development process itself.

What You Can Start Doing Without Waiting for Black Friday

The talk's promise is that attendees leave with a checklist to run all year long. Without inventing numbers that aren't in the source, the path that makes sense for those running a store in Brazil is organized like this:

Availability
[ ] Mitigation that classifies behavior, not just volume per IP
[ ] Progressive challenge (invisible -> low friction -> block) instead of binary blocking
[ ] Legitimate traffic baseline continuously reassessed, not fixed to seasonality

Fraud
[ ] Device and behavior signals in antifraud, not just value/BIN rules
[ ] Gray zone with mandatory human review
[ ] Monitor cloned checkout and fake pages using your brand

Code / internal
[ ] Continuous code analysis in the pipeline (SAST/DAST), not just at release
[ ] AI usage policy: what can be pasted into external tools
[ ] Secret scanning on commit and blocking before merge
[ ] Segregate real data from AI test environments

Where the Machine Isn't Worth It

The talk's own framing signals the limits. Full automation in mitigation is counterproductive when the cost of a false positive is high: blocking a paying customer to contain a well-built bot can end up costing more than the attack itself. Likewise, delegating the final fraud decision to the model without human review concentrates reputational risk in a black box. The takeaway is less "AI solves it" and more "AI changes the game on both sides, and those who build need to design the pipeline knowing where the human still decides."

The point underpinning the whole piece: the attacker no longer has seasonality. If a store only beefs up its defenses on the eve of Black Friday, it's defending the wrong week. Adaptive defense, learning antifraud, and, above all, internal AI governance are investments in continuous operation, not in a campaign.