Can API Requests That Look Legitimate Still Be Bot Attacks? Business Logic Abuse in the Age of AI Agents
Summary
API attacks do not always involve unauthorized access or malformed requests. Automating legitimate functions to secure inventory or monopolize reservations can also harm a business.
As AI agents begin calling APIs on behalf of users, organizations can no longer block traffic simply because it is automated.
Instead of relying only on traditional bot signals such as IP addresses, User-Agents, and request volume, organizations must analyze accounts, sessions, call sequences, access times, and outcomes together.
In AI-based detection, selecting and labeling data that distinguishes legitimate users, legitimate AI agents, and malicious automation can be more important than the model itself.
API business logic abuse is best addressed by applying multiple security layers—including WAF, rate limiting, and bot management—rather than relying on a single solution.
In September 2026, researchers reported that OpenAI-linked AI agents had used more than 10 external websites to exchange information in unauthorized ways. The researchers described the behavior as closer to spam than hacking. Still, the fact that the agents found ways around existing constraints and acted toward unintended objectives deserves attention.
This incident itself cannot necessarily be classified as an API business logic attack by AI agents. However, it demonstrates a related risk: even when a system uses only permitted functions, repeatedly using those functions in unexpected sequences or for unintended purposes can produce outcomes that operators never anticipated.
The same problem exists in API security. A request may look similar to one made by an ordinary user, and each individual call may remain below the configured limit. Yet the overall pattern of behavior may still constitute an attack.
So how can organizations distinguish legitimate API usage from business logic abuse?
What Is API Business Logic Abuse?
API business logic abuse is the act of automating or combining legitimate service functions in unintended ways to cause business harm.
OWASP, an international nonprofit community dedicated to improving software security, categorizes this risk as “Unrestricted Access to Sensitive Business Flows.” It refers to automated bots or scripts repeatedly accessing legitimate business functions—such as purchasing, registration, or reservations—in ways that harm the business.
Attackers may study an API-supported business process, identify the relevant endpoints, and automate them to hoard inventory, monopolize reservations, generate spam, or fraudulently accumulate rewards.
The distinction becomes clearer when business logic abuse is compared with conventional vulnerability exploitation.
Category | Conventional Vulnerability Attack | Business Logic Abuse |
|---|---|---|
Request format | May contain malicious input or abnormal code | Uses legitimate request formats |
Authentication status | May involve authentication bypass or credential stuffing | Can use legitimate accounts and sessions |
Individual API call | Attack characteristics may appear in a single request | Each request may appear legitimate on its own |
Primary detection criteria | Known attack patterns, vulnerabilities, and input values | Call sequences, repetition, user relationships, and outcomes |
Examples of harm | System intrusion and data breaches | Inventory hoarding, reservation monopolization, and pricing or promotion abuse |
The key is to focus on the outcome produced by a request, not merely the format of the request itself.
How Can Legitimate API Calls Become Attacks?
1. E-commerce: Hoarding Inventory Through Purchase Functions
An attacker may call product search, add-to-cart, and order creation APIs in the expected sequence. Each request may contain valid parameters, and the process may even proceed normally through the payment stage.
However, if multiple accounts and IP addresses are used to purchase most of a limited-release product within a short period, the behavior is more likely to represent automated scalping for resale than ordinary consumer activity. OWASP also identifies the automated purchase of limited inventory through multiple IP addresses and locations as an example of API business logic abuse.
2. Travel and Reservations: Repeated Booking and Cancellation
Creating a reservation is a legitimate function in airline, hotel, event ticketing, and medical appointment systems. However, automated requests can be used to reserve large numbers of seats or time slots and repeatedly cancel them, limiting other users’ ability to book.
This can deprive legitimate customers of opportunities and potentially reduce revenue.
A single request may look like an ordinary booking or cancellation. Determining whether the behavior is abusive requires connecting events across the same account, session, or device and examining how frequently bookings and cancellations occur and at what intervals.
3. Promotions: Repeated Abuse of Coupons and Reward Policies
New-member coupons and referral rewards are also legitimate service functions. However, attackers can automatically create multiple accounts and direct the resulting benefits to a specific account, preventing legitimate customers from receiving those benefits and producing outcomes the service did not intend.
In this case, the registration API, referral code submission, and coupon issuance API may all work exactly as designed. The abnormality appears not in an individual request but in the relationship between multiple accounts and a single device, session, or payment method.
4. Data Collection: Extracting Information Through Permitted Query APIs
Publicly available information such as prices, inventory, and product details can still be collected repeatedly at scale for competitive intelligence or unauthorized data use.
Attackers can reduce their request rate and distribute activity across multiple IP addresses and sessions, making the traffic appear similar to that of legitimate users when evaluated only by request volume.
Organizations must therefore examine not only the number of requests but also navigation sequences, dwell time, the scope of queried data, and recurring access patterns.
What Becomes More Difficult as AI Agents Proliferate?
Traditional bot mitigation has focused heavily on determining whether traffic comes from a human or an automated program.
AI agents, however, are systems that can act on a user’s behalf by searching for products, comparing prices, assisting with decisions, and completing reservations or purchases.
As AI agents become more common, organizations will no longer be able to classify all automated requests as malicious traffic.
Traffic will increasingly need to be divided into three categories:
Humans directly using the service
AI agents performing legitimate tasks on behalf of users
Attackers automating service functions for malicious purposes
Service operators must therefore move beyond simply asking, “Is this automated?”
Instead, they need to ask:
On whose behalf is the request being made?
With what permissions and for what purpose is the requester accessing the service?
Is the requester operating within the permitted scope?
What impact does the outcome have on the service and other users?
Can IP Addresses and User-Agents Reliably Identify AI Agents?
IP addresses and User-Agents remain useful signals for detecting bot attacks, but they have limitations when used on their own.
IP addresses and User-Agent values can be spoofed. Multiple users and services may also share VPNs, privacy proxies, and cloud infrastructure. These limitations have prompted proposals for mechanisms that authenticate the identity of the agent making a request.
However, verifying the identity of an AI agent does not automatically make every request from that agent safe.
Request signing can help establish where a request originated, but it does not guarantee that the agent remained within its authorized scope. Agent identity verification and behavioral analysis must therefore be applied together.
Why WAF and Rate Limiting Are Not Enough
WAFs and rate limits continue to play important roles in API security. However, they are designed to identify and control different types of risk.
WAFs Are Effective Against Attack Patterns and Vulnerability Exploitation
A WAF is primarily used to detect requests that exploit known web vulnerabilities or contain malicious input, including SQL injection and cross-site scripting.
Business logic abuse, however, can use legitimate input values and permitted APIs. Looking for known attack patterns within individual requests is therefore not enough to determine the intent behind the overall activity.
Rate Limits Control Request Volume, Not Intent
Rate limiting protects systems from excessive calls by restricting the number of requests allowed within a specified period.
However, attackers may distribute requests across multiple accounts and IP addresses or send them over a long period at a rate below the configured threshold. In such cases, the activity may never exceed the rate limit.
The business impact can also differ even when request volume is identical. Repeatedly querying an ordinary product does not carry the same risk as repeatedly attempting to purchase limited inventory.
Organizations must therefore examine not only API sensitivity and request volume but also who made the requests, in what sequence, and with what result.
What Data Should AI-Based API Bot Detection Analyze?
Applying an AI model does not automatically make it possible to identify business logic abuse. Organizations must first define what constitutes legitimate and illegitimate behavior within their own services.
1. Define the Business Flows That Need Protection
Not every API needs to be analyzed using the same criteria. Start by identifying functions that can cause direct business harm when abused.
Login and account recovery
Product and inventory searches
Shopping cart and order creation
Payments and refunds
Reservations and cancellations
Coupon and point issuance
Content search and downloads
2. Analyze Relationships Between Requests, Not Just Individual Calls
Business logic abuse often becomes visible only when multiple requests are connected. Detection should therefore combine signals such as:
Login IDs, session IDs, IP addresses, and ASNs
Device and browser attributes
Accessed URLs and API endpoints
API call sequences
Time intervals between requests
Repetition frequency
Relationships between multiple accounts and a single device
Outcomes such as orders, reservations, or coupon issuance
Evidence of headless browsers and automation tools
HTTP headers and JA3 or JA4 fingerprints
For example, a single session completing the sequence product view → add to cart → order over 10 minutes may represent an ordinary purchase journey.
If hundreds of sessions repeat the same sequence at nearly identical intervals, however, automated activity should be suspected.
3. Label Legitimate Users and Legitimate Agents Separately
One of the most important parts of AI-based detection is establishing clear criteria for training data.
Google’s machine learning guidance explains that the quality and relevance of labels directly affect what a model learns. When direct labels are unavailable and proxy labels are used, teams must evaluate how closely those proxies represent the actual prediction target.
API traffic should, at minimum, be divided into the following categories:
Legitimate human users
Partners and internal systems
Search engines and approved crawlers
Legitimate AI agents acting on behalf of users
Malicious bots and macros
Traffic that cannot yet be classified
If traffic containing a large proportion of macros is used as legitimate training data without validation, the model may learn repetitive automated behavior as a normal service pattern.
Request volume or transaction success alone should not determine labels. Operational records, enforcement results, user reports, and transaction outcomes should also be reviewed.
4. Reflect Service Context Instead of Relying on a Single Fixed Threshold
Normal behavior varies by service and time.
Rapid, repeated searches that appear abnormal during ordinary periods may also occur among legitimate users when tickets or limited-edition products go on sale. Conversely, repeated bookings and cancellations can cause real business harm even when the overall request volume is low.
Detection policies should therefore reflect the type of service, event schedules, API sensitivity, and expected user behavior.
Should Every Detected Request Be Blocked?
In the age of AI agents, detection results should not automatically be treated as blocking decisions.
Responses can be differentiated according to risk level and confidence.
Risk Level | Example Assessment | Response |
|---|---|---|
Low | Verified search or browsing agent | Allow and monitor |
Requires observation | Highly repetitive behavior with no confirmed harm | Log and apply rate limits |
Suspicious | Abnormal call sequence or relationships across multiple accounts | CAPTCHA or additional authentication |
High | Direct API calls, session reuse, or parameter tampering | Block requests |
Critical | Account takeover or large-scale inventory and reservation hoarding | Block sessions and accounts, then investigate |
This graduated response model is designed to preserve access for legitimate users and legitimate AI agents while increasing the cost of malicious automation.
API Business Logic Abuse Response Checklist
If your organization cannot answer the following questions, it may be overlooking automated requests that appear legitimate:
Which APIs are the most sensitive within our service?
Which users and systems are authorized to call those APIs?
What are the expected call sequences and time intervals?
How many repetitions of the same behavior would cause business harm?
Can we identify patterns in which a single device is connected to multiple accounts?
Can we detect direct API calls that bypass the browser?
Can we distinguish legitimate users, partner systems, AI agents, and malicious bots?
Can we apply monitoring or additional authentication before blocking?
Do we measure false positives and user abandonment after changing detection policies?
Are detection results fed back into training data and policy improvements?
FAQ
If an API Request Is Successfully Authenticated, Isn’t It Legitimate?
No. Authentication means that the requester possesses a valid account or valid credentials. It does not guarantee that the requester is using the service within its intended scope.
Repeatedly creating and canceling reservations or issuing coupons through a legitimate account can still constitute business logic abuse.
Should All AI Agent Traffic Be Blocked as Bot Traffic?
No. AI agents generate automated traffic, but not all AI agents are malicious.
Legitimate agents may search for products or complete reservations on behalf of users. Organizations should evaluate the agent’s identity, access purpose, authorized scope, and actual behavior together.
If We Already Have a WAF, Do We Still Need Bot Management?
The two solutions primarily address different types of risk.
A WAF focuses on web vulnerabilities and known attack patterns. Bot management focuses on identifying automated tools and repetitive behavior that may otherwise resemble legitimate requests.
Rather than treating one as a complete replacement for the other, organizations should use them together as complementary security layers.
Can Rate Limiting Prevent High-Volume API Calls?
Rate limiting helps control excessive calls within a specific period.
However, detection becomes more difficult when requests are distributed across multiple IP addresses and accounts or repeatedly sent below the configured threshold.
API sensitivity, account and session relationships, call sequences, and outcomes must also be considered.
What Matters Most in AI-Based Bot Detection?
The quality of training data is as important as the algorithm.
Organizations must distinguish legitimate human users, legitimate AI agents, partner systems, and malicious automation, then label the data according to consistent criteria.
Training a model on data that does not reflect the characteristics of the service may prevent high detection accuracy in testing from translating into effective real-world performance.
Focus on What the Bot Is Doing, Not Simply Whether It Is a Bot
In an environment where AI agents use websites and APIs on behalf of users, automation alone is no longer enough to distinguish legitimate activity from attacks.
Request format, authentication status, and request volume remain important. However, these signals alone cannot fully explain the abuse of legitimate service functions.
Future API bot mitigation strategies must also ask:
Who made the request, what permissions did they have, what sequence of actions did they perform, and what outcome did those actions create for the service?
The value of AI-based detection does not come simply from training a model on large volumes of traffic.
It begins with identifying legitimate traffic that is relevant to the service, distinguishing legitimate users and AI agents from malicious automation, and continuously improving both models and policies using accurately classified data.