Radware Thailand PoP Launch opening slide, Ritz-Carlton Bangkok, 8 Oct 2026
Photos taken by the author at the event; slide content is Radware's.

On 8 October 2026 Radware held its Thailand PoP launch for customers and partners at the Ritz-Carlton Bangkok, under the theme "Investing in Thailand's AI and Security Transformation: Technology. Talent. Trust." I went as a network and security engineer, and I took photos of nine slides. This post is what I think those slides mean, written for executives who will never read a WAF log but do own the risk those logs describe.

Everything below comes from those slides unless I say otherwise. They are vendor material, so treat the numbers as claims, not measurements.

The news: a new cloud security service center in Thailand

Radware at a glance (company-claimed figures)

Radware Cloud Security Services overview

Radware announced a new cloud security service center in Thailand (its newsroom carried the release in the week of the event). On the slides, the company describes itself as 1,200 people, 40 Tbps of global mitigation capacity and more than 60 cloud security centers. I could not verify those figures independently, and the slides say nothing about how much capacity the Thai site has.

What it means for the business. Traffic cleaning closer to Thai users should mean lower latency during an attack, and it gives regulated companies a simpler answer to "where does our traffic go?". Be careful with that last point. A local scrubbing site does not automatically mean local TLS termination or local log storage. Ask the vendor those two questions in writing before you assume data residency.

The slide that stayed with me: "The customer who logs in perfectly"

Slide: The customer who logs in perfectly

The scenario is simple. The username and password are correct. The API calls are normal. The steps happen in the right order. Every control you own says "good customer." In reality it is stolen credentials replayed at scale, a bot that has learned your app's flow, or a script that follows your process more accurately than a human would.

The slide's conclusion: signatures only catch what is already known to be bad, and only behaviour reveals bad intent.

Technical read. I agree with the direction and with a caveat. Behavioural detection is the only thing that works once the attacker holds valid credentials and rotates through residential proxies, because there is no bad signature to match. The caveat is that behavioural models produce false positives and need tuning against your own traffic. Nobody can promise you zero friction.

What it means for the business. Account takeover looks like normal revenue activity until the chargebacks and customer complaints arrive. If your fraud team and your security team look at different dashboards, this is the gap between them.

"Nothing is broken. That's the problem."

Slide: Nothing is broken. That's the problem (business logic abuse)

The second slide I would show a board is about business logic abuse. Three examples were on it:

  • Parameter tampering: changing amount: 10 to amount: 1000 in a POST /api/transfer request that the application trusts.
  • Sequence abuse: skipping the Approve step in a Submit, Verify, Approve, Receive flow.
  • Scraping: pulling rates, offers and customer data at machine speed.

No CVE is involved, no exploit payload, no alarm. Each request is a valid API call. The slide's own summary was that a valid API is being used against you.

Technical read. This is the class of issue that scanners and signature-based WAF rules (including the OWASP Top 10 sets) tend to miss, because the request is well-formed and the flaw is in the business rule. Finding it takes someone who understands the workflow and asks what happens if a step is skipped or repeated. Runtime API behaviour analysis helps, but design review and server-side validation are still your first line.

What it means for the business. Your penetration test report can be clean and you can still lose money this way. Ask whether your last test included abuse of business flows, not only vulnerability scanning.

Three questions Radware says every security practitioner should be able to answer

Slide: Three questions every security practitioner should be able to answer

  1. Before go-live: do you know every API and AI agent you have exposed, including shadow ones?
  2. In production: who protects those APIs and agents while customers, apps and AI agents are using them?
  3. Over time: how do you track behaviour and score risk as it changes?

The slide's test is that if your answer starts with "I think so," you have found a gap.

I think this is the most useful thing in the whole deck, because it costs nothing and it works on any vendor. Put these three questions to your own security lead. The honest answer to the first one is often a spreadsheet that is out of date.

The second half: AI agents as a new attack surface

Slide: Enabling AI business initiatives securely

Slide: Solution architecture, approved vs unmanaged agents

Slide: Agentic AI protection must include runtime security

The later slides moved to what Radware calls its Agentic AI solution. As presented:

  • A policy enforcer that discovers, classifies, enforces and monitors AI agents.
  • A split between approved agents (custom-built ones, developer tools on desktops, platforms such as Teams and Slack) and unmanaged "shadow AI" (desktop apps, browser extensions).
  • A compliance mapping that listed the EU AI Act, GDPR, NIST AI RMF, ISO/IEC 42001 and others.
  • A claim that agent protection must include runtime security, in two layers. At the agent level, real-time detection of misuse, prompt injection and tool abuse. At the LLM level, a configurable policy module covering prompts, data and privacy, content safety, file attachments and resource usage.
  • A traffic path: Internet, DDoS, firewall, WAF, bot management, LLM guardrails, then the agents with a behavioural layer.

Technical read. I like that it is drawn as an extension of the existing traffic path instead of a separate AI product. Where I am cautious: the behavioural layer for agents is the newest and least proven part, and the slides gave no detection rates or false positive figures. If you evaluate it, ask for a proof of concept on your own agents and measure it.

What it means for the business. Employees are already using AI tools that IT never approved. The risk is not the tool itself. It is that an agent can act with a person's permissions, so one successful prompt injection becomes an authorised action. You need an inventory of agents the same way you need an inventory of laptops.

What I would do on Monday

  • Ask your security lead the three questions above and write down the real answers.
  • Ask your API owners which business flows can be skipped or repeated, and who has tested that.
  • Ask any vendor, Radware included, where TLS terminates and where logs are stored, in writing.
  • Start an inventory of AI tools and agents in use, approved or not.
  • If you evaluate behavioural detection, run it on your own traffic and judge the false positive rate yourself.

Where I stand

The common thread in the event was that the attacker has already passed authentication. Defence therefore moves from "who got in" to "what are they doing now," and that needs visibility into behaviour, not just a longer rule list. That conclusion holds whichever vendor you pick.

I have not tested any of Radware's products for this post. This is a review of a presentation, not of a product.

Sources

  • Radware Thailand PoP Launch, Customer & Partner Plenary, Ritz-Carlton Bangkok, 8 October 2026 (slides photographed by the author).
  • Radware newsroom, "Radware Expands Global Cloud Security Network with New Security Service Center in Thailand": https://www.radware.com/newsroom/

ไทย / Thai version: https://dev.to/supachai/phuuocchmtiithiilkinthuukthukyaang-riiwiwngaan-radware-thailand-pop-launch-cchaakmumwiswkr-2463