At 02:40 on a Tuesday, a digital bank’s login endpoint handled 41,000 requests in ninety minutes. Every one was well-formed: correct content type, valid JSON schema, no injection strings, no oversized payloads, no anomalous headers. The WAF logged nothing because there was nothing to log. Each request, examined alone, was indistinguishable from a customer opening the app on the way to work.
They came from thousands of residential and mobile IP addresses across four countries, at two to five per source per hour, from real browser engines with real TLS fingerprints, because they were real browser engines driven by automation. A tiny fraction succeeded. Those successes were the point.
By the time the fraud team noticed, days later, the failed logins had been washed out of the dashboards by normal traffic, and the successful ones had already been used to change registered mobile numbers on live accounts.
Nobody exploited a vulnerability. Nobody sent a malformed request. No rule was broken, because the abuse was never in a request. It was in the pattern those 41,000 requests made together, and no control in that bank’s stack was looking at patterns. They were all looking at requests.
That scene is a composite, but nothing in it is unusual. This is the shape of most API and bot abuse now. The individual transaction is clean. The intent is not.
Four controls, each answering a different question
In the architecture diagram this is solved. There is a WAF in front of the applications, an API gateway with authentication and rate limits, a CDN with a bot management toggle, and a SIEM collecting logs from all three. Each box is doing what it was bought to do. The problem is that all four were designed around a model of the internet that no longer describes your traffic.
A WAF is a content inspector. It works when the attack is inside the payload: a SQL fragment, a script tag, a traversal string. It has no opinion about a request containing nothing but a valid username and a valid password, because there is nothing there to object to. The WAF is not failing. It is answering a different question than the one you now need answered.
An API gateway enforces identity and quota. It confirms the token is valid and the caller is under their limit. It does not know whether that token is being used the way the customer has ever used it, whether the account behind it was taken over an hour ago, or whether a partner integration is quietly enumerating your product catalogue one legitimate call at a time.
Bot management at the edge is largely a fingerprinting and challenge exercise. It classifies clients by how they present themselves. That worked when automation looked like automation. It works far less well when the automation is a real browser engine routed through a residential proxy pool, presenting itself as a mid-range Android handset on a South Asian mobile network, because for network purposes that is what it is.
Your SIEM sees all of this faithfully, in aggregate, hours later, at a granularity that answers “was there a spike” and not “was there intent”.
The gap is not in tooling budget. It is in the question being asked. Every one of these controls evaluates events. The abuse lives in the relationships between events: the order they arrive in, the accounts they touch, the objects they walk through, the rhythm they keep, and how all of that compares with normal use of that specific endpoint by real people.
Where the abuse actually lives
- Your API estate is larger than your application estate
A decade ago an organisation ran a dozen web applications and the APIs behind them were an implementation detail. Today a single mobile banking app fronts dozens of endpoints, the web channel adds its own, partner and aggregator integrations add more, and every microservice refactor multiplies them again. The APIs now outnumber the applications they were built to serve.
Worse, they persist. When version 4.2 of your mobile app shipped, version 3.8 endpoints stayed live, because forcing an upgrade on older devices was commercially unacceptable. They are still authenticated, still functional and still returning data, but nobody has reviewed them since the developer who wrote them left. They are not in the API catalogue, not in the gateway policy, and not in the last penetration test scope, because the scope was drawn from the catalogue.
Attackers do not work from your catalogue. They work from decompiled mobile app bundles, JavaScript source maps and traffic observation, which surface the endpoints your documentation forgot.
- The abuse is in the sequence, not the request
Consider a retail loyalty API with an endpoint that checks a points balance for a member number. It is authenticated, rate limited to sixty calls a minute, and every call is perfectly formed.
A customer calls it twice a month. An attacker calls it once every eleven seconds, from a different source each time, walking member numbers in a slowly incrementing pattern, for six weeks. Each call is legal. The sequence is a full enumeration of your membership base and a map of which accounts are worth cashing out.
Or take a wallet transfer flow designed as a four-step sequence: validate recipient, quote fee, confirm, execute. An attacker who calls step four directly, or step one two thousand times without reaching step four, has not broken the API contract. They have broken an assumption that was never written down anywhere a security control could read.
This is business logic abuse, and signature-based defences have nothing to offer here. There is no signature for “used the API correctly, for the wrong reason”.
- Credential stuffing that looks exactly like your customers
Credential stuffing is no longer a volumetric attack, because attackers learned that volumetric attacks get blocked. The current pattern is distributed, patient and cheap: a large pool of residential and mobile proxies, real browser automation, a per-source request rate that sits comfortably under any static threshold you would dare to set, and stolen credential pairs from breaches elsewhere.
The rate limit that would stop it would also stop a shared mobile carrier NAT gateway, which in several markets fronts tens of thousands of genuine subscribers on a handful of public addresses. Block the IP and you have blocked a district. Geo-block and you have blocked your diaspora customers, frequently your highest-value remittance users.
An attacker with a very low success rate only needs volume, and volume spread across enough sources is invisible at any single source. Across South Asia, Southeast Asia and the Middle East this is the general condition, not an edge case: carrier-grade NAT, single corporate egress points and district offices behind one address mean every block decision is a decision about a population rather than an individual.
- Scraping that is a direct transfer of margin
In airlines, fare and availability scraping by aggregators and unauthorised metasearch is not a data breach. It is a cost line. Every scraped query consumes an inventory lookup, and in many distribution arrangements that lookup carries a real per-transaction cost, incurred so a third party can undercut your direct channel with your own data.
In retail and e-commerce the same mechanic drives price scraping, stock monitoring and gift-card balance checking. Gift-card enumeration is especially instructive: the attacker is not stealing data, but testing card numbers against a balance endpoint until one has value, then draining it. Every request is a valid balance query. The abuse is the ten million of them.
Scalping compounds this. When a limited inventory drop or a fare sale goes live, automated clients that hold sessions warm and complete checkout in under two seconds violate no rule. They just win every time, and genuine customers learn your channel is not worth trying.
- Abuse that costs you money per request
OTP and SMS pumping deserves its own heading because a single API call here carries a direct, non-recoverable cost. An attacker triggers your “send verification code” endpoint against number ranges they earn revenue share on, or simply in volume to inflate your telecom spend. There is no data loss. There is an invoice.
The same shape appears in any endpoint calling a metered downstream service: identity verification, credit bureau queries, address validation, KYC document checks, and increasingly LLM inference behind a customer-facing feature. Each is an authenticated, well-formed request that costs money when made for the wrong reason, and static rate limits protect the platform without protecting the budget.
- Traffic that is neither clearly human nor clearly hostile
A growing share of automated traffic is legitimate, and some of it is your own customers acting through an agent. AI assistants retrieve prices, check availability, complete forms and initiate transactions on a user’s behalf. LLM training and retrieval crawlers pull content at scale. Partner integrations, monitoring probes, mobile SDK sync and service accounts all generate machine traffic that must not be blocked.
The old binary of human good, bot bad has stopped being a useful classification. The question is no longer whether a client is automated. It is whether this automation, on this endpoint, at this rate, following this sequence, is doing something the business wants to allow. Few controls in a typical stack are structured to answer that.
Why writing more rules loses you two years
When the rules stop catching the abuse, the reflex is to write more rules. This is where a lot of teams lose two years.
More rules means a growing library of conditions, each written after an incident, each tuned to one attacker’s behaviour on one endpoint at one moment. The attacker adjusts inside a day. The rule stays in the policy for three years, because nobody is confident enough to remove it. The policy becomes a record of past attacks rather than a defence against current ones, and every fossil carries a risk of blocking a genuine customer.
Tighter rate limits shift the cost onto legitimate users first. Thresholds are static and traffic is not, so a limit low enough to matter during an attack will reject real customers during a payday spike, a sale or a festival period, precisely when the business least wants friction.
More tools means more consoles, each with a partial view of the same traffic and its own verdict. The team reconciles three opinions rather than acting on one, and because none of them individually can justify a block with confidence, all get set to monitor. Adding analysts runs into the same wall: the analysis required is correlation across millions of requests per endpoint per hour against a moving baseline, which is not work a human can do at the pace it arrives.
There is a quieter cost too. Every hour spent maintaining rules is an hour not spent understanding what your APIs are for. Teams end up expert in their policy language and vague about their own traffic.
Then there is the false positive cost, which in consumer businesses is not a security metric at all. A wrongly blocked login in a digital bank is a contact centre call, an unblock workflow, an app store review, and in regulated markets a complaint that may need formal handling. A wrongly blocked checkout is abandoned revenue. Multiply that across a mobile-first customer base and it is clear why teams quietly stop enforcing. Tolerance for false positives here is near zero, so a control that cannot be trusted to be precise is never allowed to act. A control that cannot act is documentation.
How Ammune AI approaches this differently
Ammune AI starts from a different premise: you cannot recognise API abuse by comparing requests to a list of known-bad patterns, because the requests are not bad. You recognise it by knowing in detail how each API is normally used, and noticing when usage stops matching.
That sounds like anomaly detection generally. The difference is in the granularity and in where the models sit.
1. A model per API, not a policy per site
Ammune builds what it calls a “micro-AI/ML machine” for each API at each protection layer, thousands of them across a real estate, with a broader model above them reasoning across those outputs. The consequence is that “normal” is defined per endpoint, not per site.
Normal for a login endpoint is not normal for a balance enquiry, a fare search or a partner bulk feed. A single global policy has to be loose enough not to break the busiest of these, which makes it useless for the most sensitive. Per-endpoint models remove that compromise.
The learning is self-directed: the picture of normal behaviour is built from your traffic rather than a catalogue of known attacks, which is what allows it to flag abuse it has never seen before.
2. Discovery is a by-product of protection
Ammune discovers new API endpoints from the traffic flow itself and sets an adapted, AI-based protection policy for each one it finds.
Every shadow and zombie API problem described earlier exists because the control’s view of the estate comes from a document. When that view comes from observed traffic, a live endpoint is a protected endpoint, whether or not anyone catalogued it, and the discovery output doubles as an inventory for the application team.
3. Four defensive concerns, kept distinct
Rather than one undifferentiated verdict, Ammune separates the problem into separately licensed modules that map onto how the attacks differ. API-WAF handles content-based application layer attacks through deep packet inspection and AI analysis. API-BOT addresses automated bot attacks against APIs using traffic context analysis in near real time. API-DDoS covers multi-vector, application-layer denial of service, analysed at endpoint level. API-BL identifies attacks that exploit business logic flaws.
Keeping these distinct matters because the evidence for each differs. Bot detection reasons about client behaviour and timing, business logic detection about session and historical data points, applicative DDoS detection about aggregate load shape against a learned baseline. A single blended score obscures which is happening and makes the response harder to justify.
4. Signals that match the attacks in this post
The behaviours the platform reasons about are named plainly: enumeration, replay, route switching, abnormal object access, unusual response data, repeated high-value actions, unexpected sequences, and the automation of sensitive business flows.
Read that against the challenges above and the mapping is direct. Enumeration and abnormal object access are gift-card and member-number walking. Unexpected sequences are the wallet flow called out of order. Repeated high-value actions and unusual response data are what distributed credential stuffing looks like when no per-IP threshold will catch it. Automation of a sensitive business flow is what scalping and unauthorised aggregation look like from the endpoint’s side.
Because expectations are learned per endpoint from your own traffic, legitimate machine clients are part of the baseline rather than an exception to it: your nightly partner feed and your monitoring probes are normal for the endpoints they touch. That is the distinction the human-versus-bot binary cannot make.
5. It can act inline, where your traffic already is
Detection you cannot act on is reporting. Ammune offers inline integration, side-by-side integration, monitoring through a VPC traffic mirror and a side-by-side Kubernetes option, and it can run in monitoring mode or protection mode, so you can build confidence before anything is blocked. It runs on-premises, in the cloud and on containers, and there is a SmartNIC and DPU deployment path for high-throughput environments.
For organisations running modernised services alongside legacy systems that cannot be touched, the ability to start on a traffic copy and move inline later is often the deciding constraint.
Ammune also positions itself around air-gapped discovery and offline protection: analysis and response run inside your own environment rather than depending on an external service for a verdict. For banks under residency expectations, telcos under licence conditions and government portals with sovereignty requirements, that is frequently the difference between a solution and a non-starter.
Because the models learn expected patterns from traffic over time rather than from hand-written rules, per-endpoint protection becomes viable at all. Nobody is going to author and maintain policies for several thousand endpoints.
What this looks like in practice
Run the opening scenario again, this time with behavioural detection in place.
- The login endpoint already has its own model, built from weeks of observed legitimate use: typical request rate per identity, typical interval between attempts, typical sequence of calls around a login, typical distribution of outcomes.
- The campaign begins. Per-source rates stay under any static threshold, so no rate limit fires.
- What changes is the shape. Failed-to-successful authentication ratios move off baseline, attempts arrive with a machine-like regularity human traffic does not have, and individual sources touch many identities rather than one.
- Repeated high-value actions against many identities, from clients whose timing does not vary the way human traffic does, are precisely what the endpoint’s own model is built to notice, and it notices at the endpoint under attack rather than across the whole estate, so a busy checkout flow elsewhere does not dilute them.
- The verdict is scoped to behaviour, not to an address block. Clients exhibiting the pattern are acted on. The genuine customer arriving from the same carrier NAT at a human rhythm is not.
- Because it runs inline, the action happens during the campaign, not in a report three days later.
- The discovered-endpoint inventory then shows the same attacker touched two version 3.8 endpoints missing from the API catalogue, which becomes a conversation with the application team on Monday.
The difference is not better rules. It is a control asking a different question.
Where each attack meets a control
| Challenge | How Ammune AI addresses it |
|---|---|
| Every request is well-formed, so content inspection sees nothing | Per-endpoint behavioural models judge sequence, timing, identity and object access rather than payload content |
| Shadow and zombie APIs from old app versions are outside the policy | Endpoints are discovered from live traffic and given an adapted protection policy automatically |
| Distributed credential stuffing sits under any static rate limit | Repeated high-value actions and deviation from the endpoint’s learned baseline are detected without per-source thresholds |
| Blocking by IP punishes genuine users behind carrier NAT | Decisions rest on the observed behaviour of the client, not on address reputation alone |
| Business logic abuse breaks no rule because there is no rule | The API-BL module identifies unexpected sequences and automation of sensitive business flows against learned normal usage |
| Legitimate automation must not be blocked alongside hostile bots | Expected machine traffic forms part of each endpoint’s learned baseline rather than being classified by fingerprint |
| Techniques change faster than signatures can be written | A self-learning detection engine adapts from your own traffic without prior knowledge of the attack |
Who benefits most
Digital banks, wallets and fintechs, including anyone running open banking or aggregator interfaces, where business logic is deliberately exposed to third parties, account takeover carries regulatory consequences, and a false positive is a contact centre call rather than a log entry.
Telecom operators exposing self-care, top-up, eSIM and open API interfaces, carrying the direct cost of OTP and SMS pumping abuse on endpoints never designed with a cost-per-request in mind.
Airlines, travel and e-commerce platforms losing margin to fare and price scraping and trust to scalping, where abusive traffic is functionally identical to demand.
Government citizen portals and public digital services where whole districts sit behind shared egress addresses, blocking decisions carry political consequences, and residency rules constrain where analysis can happen.
The category, not the product
Application security spent twenty years learning to recognise bad content, and the attacks moved to good content used badly. That is not a gap you close by tightening what you already have, because what you already have was built to answer a question attackers stopped asking.
The organisations that handle this well stop framing it as a bot problem. Bots are a delivery mechanism. The real problem is that your APIs expose business logic to the internet, and business logic can be abused by anyone who understands it, using valid requests. Defending that requires knowing what normal use of each API looks like, in enough detail to act on a deviation at machine speed without collateral damage to the customers you are trying to serve. That is a different capability from a WAF, and it is worth being honest about whether you have it.
EGUARDIAN distributes Ammune AI across South Asia, Southeast Asia and the Middle East, working with channel partners and end customers to scope where behavioural API protection sits alongside existing gateways, WAFs and edge controls rather than replacing them. Most engagements start in monitoring mode on the endpoints that matter most, simply to see what is already happening in traffic nobody was watching.
Talk to our experts at EGUARDIAN. If your APIs carry real transactions for real customers and you are not confident you could tell abuse from demand, let’s have a practical conversation about your traffic, your constraints and what better protection would look like for your organisation. Reach out to us at hello@eguardian.com.
