The AI agent your company deployed last quarter to book flights, process purchases, or manage customer accounts looks almost identical, at the network level, to the bot your security team is working hard to block. One of them is generating revenue. The other is draining it. Most security systems still cannot reliably tell the two apart.
That problem has become acute in 2026 as autonomous AI agents move into everyday commerce, banking, and travel at scale. The bot-management logic most companies still run was built for a simpler era of web crawlers and scripts, and it was never designed to handle software that legitimately acts on a customer’s behalf at machine speed. F5’s September 2026 update to its Distributed Cloud Bot Defense product is a useful window into this, but the challenge belongs to the whole industry, not one vendor.
Here is what you actually need to understand: what has changed in the threat environment, what the new technical approaches genuinely do rather than what the marketing claims, and what any business relying on AI-driven automation should be asking before the next board conversation or procurement decision.
Why the rise of autonomous AI agents broke traditional bot defenses
For years, bot management looked like a solved problem. Traffic was either a human or hostile automation, and the job was simply to identify the hostile kind and block it. That binary held up well enough when the automation you faced was crude: scrapers, credential-stuffing scripts, and simple crawlers that behaved nothing like a real person.
Autonomous AI agents broke that binary completely.
These agents now interact with websites, apps, and customer portals on behalf of real users, completing purchases, reserving travel, and carrying out banking operations across multiple steps at high speed. The uncomfortable truth is that authorised automation now behaves almost exactly like malicious automation. Both move fast, both hit APIs directly, and both perform sequences of actions no human would type by hand.
The governance urgency F5 is responding to is not hypothetical: AI-powered cyberattacks have already demonstrated the ability to move from initial reconnaissance to a working exploit in under 72 hours, compressing attack timelines that once took weeks into days and making the window for detection far narrower than legacy bot defences were ever built to handle.
The five structural failure modes of legacy bot management
The failures are not random gaps that a few more rules could close. They are structural, and each one matters more now that AI agents are everywhere.
- Binary logic. Traditional tools assume all automation is hostile, but shopping assistants, travel-booking agents, and banking automations are revenue-generating and business-critical. Blocking them by default is no longer an option.
- Request-level blindness. Signals like IP reputation and user-agent strings evaluate one request at a time, with no longitudinal record. According to F5, these controls “cannot reliably distinguish a multi-step agent executing a legitimate workflow from an attack script replaying similar steps.”
- Application-layer opacity. Modern agents are best understood through their sequence of actions and transaction intent, not static attributes. Per-request rules simply cannot see that higher-level behaviour.
- Spoofing vulnerability. Attackers use virtualised environments and obfuscation to defeat simple fingerprints, which is why single-signal detection fails against a determined adversary.
- Identity and authorisation complexity. Agents act using API keys, OAuth tokens, or delegated credentials, so separating an authorised agent from a malicious one requires identity-centric controls, not just traffic analysis.
F5 acknowledges that blunt countermeasures like IP blocking and CAPTCHA “risk inadvertently restricting legitimate, revenue-generating AI-driven channels.” The OWASP framing sharpens the point further: distinguishing authorised AI agents from malicious bots is primarily an application-security and governance problem, not a network-level filtering task.
This is the part worth holding onto. The failure of traditional bot defences is not a gap that more rules can close. It is a category error. Any enterprise running customer-facing AI agents has already outgrown the tools most security teams still rely on, whether they realise it or not.
When big ASX news breaks, our subscribers know first
What F5’s September 2026 update actually does, and how it works
F5’s update, published on 15 September 2026 and formalised in a press release dated 23 September 2026, adds four new capabilities to Distributed Cloud Bot Defense. The interesting part is how they build on one another rather than sitting as separate features.
It starts with identity. Persistent Device Identification generates what F5 describes as a “highly resilient and stable identifier” for each device, tracking it across multiple sessions, browsers, and IP addresses “even when attackers attempt to conceal their tracks.” This is the longitudinal record that request-level tools never had.
Once that record exists, F5 can score against it. Real-Time Device Risk Scoring evaluates client integrity before a high-risk transaction goes through, looking specifically for emulators, device spoofing, and tampering, then producing an explainable risk score.
The scoring only matters if you can act on it proportionately. Risk-Based Workflow Enforcement replaces block-everything logic with graduated responses: allow, step-up challenge, rate-limit, or block. The goal is to cut the CAPTCHA friction and false positives that damage legitimate users and approved automation.
Sitting on top is the Agent-Aware Policy Framework, which classifies humans, trusted AI agents, and malicious bots within a single policy on F5’s Application Delivery and Security Platform. This is what lets an organisation explicitly welcome an authorised agent while still blocking abuse.
The device-and-account mapping is where this gets concrete. F5 uses two illustrative patterns: a single device accessing hundreds of accounts, a strong signal of account takeover, versus a single account accessed by an unusual number of devices, a possible sign of fraud or account sharing.
F5 states the product identifies and controls AI agents “based on behavior and intent, not static signatures or identity claims.”
That distinction is the line to hold. A signature-based system can be spoofed the moment an attacker learns the signature. A behavioural system requires an attacker to mimic legitimate patterns across the full interaction arc, which is far harder to fake at scale. That is the difference between a lock that opens with one stolen key and one that watches how you move through the whole building.
Adversary breakout times have collapsed to just 29 minutes according to CrowdStrike data cited in a joint letter signed by over 100 technology companies in August 2026, a compression that makes the multi-step behavioural analysis F5 is building toward even more time-critical than the product documentation suggests.
| Capability | What it does | Why it matters | Availability |
|---|---|---|---|
| Persistent Device Identification | Creates a stable identifier tracking devices across sessions, browsers, and IP addresses | Builds the longitudinal record request-level tools lack | Limited availability Q4 2026, broader rollout to follow |
| Real-Time Device Risk Scoring | Detects emulators, spoofing, and tampering, producing an explainable risk score | Flags suspicious environments before high-risk transactions complete | Limited availability Q4 2026, broader rollout to follow |
| Risk-Based Workflow Enforcement | Applies allow, step-up challenge, rate-limit, or block based on risk | Reduces false positives and CAPTCHA friction for real users | Available with agentic protections |
| Agent-Aware Policy Framework | Classifies humans, trusted agents, and bots in one policy | Lets trusted automation be managed separately from abuse | Available as of September 2026 |
The limits of device intelligence: what this approach cannot guarantee
All of that is a genuine step forward. It is also not a finished answer, and the honest read requires understanding where it stops working.
Device fingerprinting, powerful as it is, has documented failure modes that sophisticated attackers already exploit:
- Identity churning. Attackers spin up large fleets of ephemeral virtual devices, cycling through identities faster than risk models can adapt.
- Device-state manipulation. Resets, browser sandboxing, and deliberate clearing of local state can undermine persistent identifiers.
- Shared environments. Family computers, kiosks, and multi-user machines confuse attribution, blurring who is actually behind an action.
- Fingerprint degradation. Browsers, operating systems, and hardware change over time, forcing constant recalibration.
F5’s own risk scoring explicitly targets emulators, spoofing, and tampering, which tells you these techniques are already in active use. This is an ongoing arms race, and no fingerprinting scheme is future-proof against a determined adversary.
There is also a commercial caveat. These capabilities depend on proprietary client-side tags, mobile SDK telemetry, and platform-wide signals. Once a business builds revenue-critical classification around one vendor’s device IDs and risk models, switching becomes expensive and operationally risky, because historical risk models are not portable between platforms.
The governance gap no technical tool can fill
The deeper problem is one no product can solve for you. F5’s agent-aware framework assumes an organisation has already defined which AI agents are authorised, how they authenticate, and who signed off on them. Many enterprises simply have not done this work.
Three governance prerequisites need to exist before any agent-aware policy can function. First, a defined list of authorised AI agents, internal and third-party, each with its authentication method recorded. Second, a business-owner approval process for new automated workflows, so nothing goes live without accountability. Third, an ongoing review cycle to catch shadow integrations and rogue agents that slip in outside the process.
The NIST AI Risk Management Framework backs this approach, encouraging organisations to treat AI-driven automation as part of their risk inventory with governance and monitoring across the lifecycle. OWASP goes further still, arguing that even authorised agents should be treated as potential threat actors requiring robust access control, not just a one-time place on an allowlist.
The gap between voluntary AI governance frameworks and enforceable standards is the same structural problem that appears in bot-management policy: an organisation can publish a commitment to responsible agent deployment and still lack the registry, approval process, and review cycle that would make that commitment operationally meaningful.
The OWASP AI Agent Security guidance reinforces this position, recommending that even authorised agents be subject to least-privilege access controls, input validation, and continuous behavioural monitoring rather than a one-time placement on an allowlist.
The practical takeaway for a security leader is blunt. Device intelligence is a necessary layer, not a governance substitute. Deploy F5’s product, or any comparable one, without first building a registry of authorised agents and their approved workflows, and the technical controls will underperform their billing. Persistent tracking at scale also raises GDPR and CCPA questions around consent, transparency, and data minimisation, particularly when device IDs are correlated with real identities.
What this means for businesses betting on AI-driven automation
Step back from the architecture and the stakes become plainly commercial. The classification problem cuts both ways, and both directions cost money.
Misclassifying a malicious bot as a trusted agent opens the door to fraud, credential stuffing, and inventory manipulation. Misclassifying a legitimate AI agent as a malicious bot blocks revenue and damages customer experience. Both are expensive failures, not just one.
| Misclassification type | What happens | Business impact | Who bears the cost |
|---|---|---|---|
| Blocking a legitimate agent (false positive) | Trusted automation is challenged or blocked mid-workflow | Lost transactions, higher abandonment, eroded customer trust | Revenue and customer-experience teams |
| Missing a malicious bot (false negative) | Attack traffic mimicking legitimate behaviour gets through | Credential stuffing, chargebacks, fraud losses, incident response | Fraud, security, and finance teams |
This is why the bot-management market is growing the way it is. Estimates put the 2025 market at between $1.2 billion and $2.0 billion across credible research sources, with compound annual growth of roughly 15% to 17% projected into the early-to-mid 2030s. That trajectory reflects genuine enterprise urgency rather than hype, because the volume of AI-agent traffic is rising in direct proportion to enterprise AI adoption.
The competitive field is concentrated. Dataintelo’s 2025 analysis names Akamai Technologies, Cloudflare, Imperva, F5 Networks/Shape Security, and Human Security as the top five vendors, collectively holding an estimated majority of global bot-management revenue.
The number to read into is not the market size itself. It is what the growth signals: enterprises across every sector are realising that their AI deployment roadmap and their bot-management infrastructure are now the same conversation, not two separate line items in the IT budget.
For any business deploying customer-facing agents, the orientation is simple regardless of which vendor you pick. Can your current bot-management layer classify authorised automation separately from malicious traffic? And is that classification based on behavioural signals, or only on static attributes an attacker can copy? If the answer to either is uncertain, that is a latent liability sitting under a revenue-generating system.
What businesses should actually do before the next AI deployment
The sequencing principle matters more than the product choice. Technical controls are only as good as the governance beneath them, so the first moves are organisational, not procurement.
Work through three steps in order:
- Audit the AI agents already operating on your customer-facing systems, both internal builds and third-party integrations. You cannot protect what you have not counted.
- Establish an authorisation registry, recording each agent’s authentication method and the business owner who approved it. This is the foundation any agent-aware framework depends on.
- Evaluate your bot-management tooling only after the first two steps, checking whether it classifies agents by behaviour and intent rather than static signatures.
When you reach that evaluation, apply consistent criteria across any vendor you assess:
- Behavioural detection versus static signature matching
- Policy granularity, from allow through step-up challenge to block
- Support for trusted-agent allowlisting
- Integration with your governance and monitoring processes
The NIST AI RMF frames this as treating AI-driven automation as part of your risk inventory with ongoing accountability, and OWASP reinforces that authorised agents still require continuous access control and monitoring. F5 states its own design goal as enabling organisations to “welcome trusted digital interaction while stopping automated fraud and abuse,” which is a useful benchmark to measure any tool against, not a guaranteed outcome of buying one.
Treat this as a recurring review cycle rather than a one-off project. AI-agent deployment is accelerating, and the classification challenge compounds with every new integration added to your systems. The reader who leaves with a three-item governance checklist is in a stronger position than the one who leaves with a vendor shortlist, because the governance gap is the more common and more expensive failure in practice.
This article is for informational purposes only and should not be considered financial advice. Investors should conduct their own research and consult with financial professionals before making investment decisions. Financial projections are subject to market conditions and various risk factors.
The security layer underneath enterprise AI is now a strategic question
The rise of autonomous AI agents has quietly turned bot management from a security commodity into a strategic infrastructure question. The same technical layer that blocks malicious automation must now also protect and enable the legitimate, revenue-generating agents your business increasingly depends on. Those two jobs used to be separate. They are now one.
F5’s September 2026 update points the market in a credible direction, toward classification based on behaviour and intent rather than static signatures. But no current solution, F5’s included, removes the governance work an organisation has to do for itself. The registry, the approval process, and the review cycle remain your responsibility.
The broader implication is worth sitting with. As AI adoption accelerates, businesses that treat agent security as a foundational concern from the outset, rather than a retrofit after deployment, will carry noticeably less operational and financial risk than those who wait for a misclassification to make the case for them.
