Application abuse and what to do about it [Q&A]

Using applications as an attack vector, in a DDoS campaign for example, is not new. But application abuse is evolving making it harder to spot.

We spoke to David Mytton, CEO of runtime security specialist Arcjet, to discuss how attacks have changed and why traditional security methods are struggling to keep up.

BN: Application abuse today looks very different than it did even a few years ago. What do most teams still get wrong about how abuse actually manifests inside real production systems?

DM: Teams still treat abuse as loud, network-level noise and tune edge controls accordingly. Today’s abuse is quieter and lives in business logic: account creation, form flows and multi-step journeys. The mistake is thinking in isolated requests instead of sequences and outcomes — so low-volume, high-value attacks (account stuffing, automated signups, scraping that respects rate limits) slip through. Treat abuse as a product-quality problem inside the app, instrument request sequences and business results, and you’ll find the real signals.

What teams also miss is how ‘normal’ abusive traffic now looks. The days of DDoS attacks just being volumetric are over — the cloud platforms mitigate those types of attack for you. Edge protections can’t properly tell the difference between what is normal for your product, your users, or across different classes of users e.g. enterprise vs free accounts. This means the request context is important — your defenses need to be able to distinguish between free account abuse and your largest customer making legitimate requests.

BN: As attacks have shifted from infrastructure toward business logic, why have traditional perimeter-based defenses struggled to keep up?

DM: Firewalls and proxies see transport and headers; they do not see application state, session history, or intent. Business-logic attacks exploit state and flow — authenticated users, tiny well-timed request chains, or actions that only look malicious once correlated. Perimeter controls are brittle against that. The only reliable place to reason about these attacks is where the logic and context live: the application layer.

There is also an organizational mismatch. Perimeter tools are owned by security teams optimizing for uniform policy, while business logic is owned by product teams optimizing for growth and conversion. That separation means the defenses are structurally blind to what ‘bad’ actually means for a given flow. As long as abuse detection sits outside the application, it will lag behind application changes by design.

BN: AI has radically changed the economics of abuse. How does automation on the attacker side alter the kinds of trade-offs defenders now have to make?

DM: Automation amplifies scale and speed: attackers can run thousands of cheap experiments and stitch small wins together. Defenders therefore face two hard trade-offs — act fast and risk false positives, or be precise and give attackers time to iterate — and must budget resources between shallow broad guards and deep, costly checks. The practical response is layered controls: cheap global throttles to slow mass abuse, plus high-fidelity, context-aware checks on high-value flows.
Crucially, defenders are no longer reacting to static techniques but to adaptive systems. Attackers can now A/B test defenses, probe decision boundaries, and adjust behavior in hours, not weeks. That forces defenders to think less in terms of permanent rules and more in terms of continuous calibration and cost imposition. The goal is to make abuse expensive enough that attackers move on.

BN: Security teams often optimize for blocking threats, while product teams worry about user friction. Why is minimizing false positives becoming one of the hardest — and most important — problems in modern application security?

DM: Every mistaken block costs conversion and user trust. Modern users (API clients, headless browsers, AI agents acting on behalf of users) look more like attackers, so simple heuristics break down. Minimizing false positives requires richer context (session history, business signals) and the ability for product teams to tune enforcement per flow.

False positives are especially dangerous because they are silent failures: the user just leaves. Unlike attacks, they rarely generate alerts. That means teams systematically under-report the damage. The only sustainable approach is to treat enforcement like a product surface — observable, tunable, and reversible — rather than a one-way gate.

BN: With AI agents and automated clients acting on behalf of users, how should developers rethink concepts like identity, intent, and trust at the application layer?

DM: Identity must be multi-dimensional and probabilistic — device, session, credential provenance and behavioral history — not a single token or IP. Intent is the signal: what is the client trying to do and why does it matter to the business? That changes throughout the application which is why the context is so important — trust should therefore be action-scoped, short-lived and revocable.

In practice, this means stopping the search for a single ‘good vs bad’ verdict. A client might be trusted to browse, partially trusted to transact, and untrusted to automate. Trust should decay naturally and be re-earned through behavior, not granted once and assumed forever.

BN: Looking ahead, as more traffic becomes non-human, what does ‘effective security’ actually mean for modern applications?

DM: Security must be built as a product platform — give teams the primitives so they can choose where to accept friction and where to be strict. Then measure outcomes and iterate. Treat actions (checkout, payout, signup) as the unit of work and make dynamic, action-scoped trust decisions. Security should be platform engineering: guardrails that let teams move fast and stay safe.

Effectiveness will be measured less by blocks and more by business resilience: stable conversion, predictable abuse losses, and the ability to ship new flows without reopening old holes. In that sense, modern application security is less about stopping attackers outright and more about keeping the system economically and operationally sane under constant pressure.

Image credit: denisismagilov/depositphotos.com