The answer is probably both yes and no. :-)

AI agents are starting to give us a similar feeling.

We give them a goal, teach them what they can do, and then they start making their own decisions about how to get there.

And this creates an interesting security question: What happens when the agent is not hacked, but chooses a path we never intended or authorized?

This is the focus of our latest blog about Agentic AI security.

It explains why looking only for known attacks or malicious activity may no longer be enough. We also need to understand what the agent was supposed to do, and recognize when its behavior starts moving away from that goal.

👉 Read the full blog written by Dror Zelber: https://www.radware.com/blog/beyond-signatures-and-sandboxes-ai-agent-security/

And I’m curious: Have you already seen an AI agent do something that made you think, “I definitely didn’t tell you to do that”? 🙂

Dror Zelber

Attack automation is accelerating, AI agents are becoming more capable, and the time available to patch vulnerabilities keeps shrinking.

Join Pascal Geenens for an insider's view of what he's seeing on the front lines and the trends security teams should be paying attention to right now

Click to register:

EMEA/NA/CALA

APJ/EMEA

I have an application inside a secure network, we use an Alteon to publish/deliver the applications to a less secure zone. The desire is to have the "public" zone at https://appname.dot.com - the secure application is at https://10.11.12.100:3000 the authentication redirects inside to https://10.11.12.100:443 and then back to :3000 when successful.

The product is Sandvik Optimine and the desired page is Machine Alerts - https://10.11.12.100:3000/app/machinealerts

• Client HTTPS 443

• v

• https://appname.dot.com

• v

• Alteon HTTPS VIP:443

• |

• +-- Request path starts /sso --> HTTPS 10.11.12.100 (:443)

• |

• '-- All other paths --> HTTPS 10.11.12.100:3000

The Real Server is configured with two ports 443 & 3000

I have tried Content Rules to separate the applications, however a Content Rule does not seem able to specify the destination port number 😢 - I need somehow to specify standard https/443 for the initial authentication prompt (when the path includes /sso/)

Has anyone published Sandvik Optimine Machine Alerts? OR a web app that uses multiple internal ports?

I’m curious how real this feels within your organization. Have you witnessed it firsthand, or heard similar stories from colleagues? Is this still mainly an IT and CISO concern, or are management and other stakeholders now asking what the organization plans to do about it? Most importantly, what, if anything, are you planning to do differently?

We have identified some cases, in the most of all we have analyzed the developments they are doing, we use to make a risk assessment and, fortunately, they had our permission and advice. In one case we didn't allow the activities one area was doing because had some risks uncontrolled.

Our H1 2026 Global Threat Analysis Report reveals that cyberthreats have crossed an automated tipping point. Driven by autonomous AI agents, direct-path volumetric floods, and a 110% surge in Web DDoS, attacks now strike at scale and at machine speed.

Is your defense as agile as the threat?

Read the full report: H1 2026 Global Threat Analysis Report
The executive summary: H1 2026 Global Threat Analysis Report - Executive Summary
Check the infographic: H1 2026 Global Threat Analysis Report - Infographic

Read my companion blog: Cyberthreats Reach the Automated Tipping Point

And join me on October 1 during the report webinar: "The Automated Tipping Point: AI Agents, Zero-Day Exploitation and the H1 2026 Threat Landscape" — reserve your seat here: NA/CALA | EMEA/APAC

Stay frosty!

Pascal.

Had an interesting one this week - worth sharing with you. You probably assume there are plenty of interesting success stories crossing my desk, but the ones I choose to share with you have something beyond just "a big attack got stopped."

A major MVNO - the kind that delivers connectivity and IoT services across 200+ countries - took a hit this week. Not "just another attempted breach" - a real web DDoS attack, on the platform that manages all their critical services: administration, monitoring, configuration, for millions of users.

A globally distributed botnet launched 140,000 HTTPS requests per second. For 15 straight minutes. That's nearly 5,000 times their normal traffic!

Stop for a second on that number. 5,000x. If this had succeeded, we're not talking about a website going down - we're talking about basic connectivity services disappearing for millions of people who just wanted to make a call or get online.

It didn't succeed.

The system caught it instantly, mitigation kicked in automatically, and service kept running like nothing happened.

Now, when I said at the start that this was an interesting story - here's the part where I get to why. HTTPS flood attacks like this don't look like attacks at all. They look like real users. So you're not fighting volume - you're trying to tell apart, in real time, 140,000 requests a second that all look basically identical, and figure out which ones are a person and which ones are a bot. No one sitting there making that call by hand. It's AI that's learned what "normal" looks like for this specific customer, generating precise mitigation signatures automatically, within seconds. And here's the best part of the story - not one subscriber knew this happened. Not one. And isn't that exactly the measure of success?

This is the thing I keep trying to say in these posts:

DDoS protection isn't measured by how much traffic you blocked. It's measured by whether your customers kept doing what they came to do, without ever noticing someone tried to stop them.

So, honestly, a question for you:

• If someone hit you tonight with 5,000x your normal traffic - would you know within seconds that it's an attack and not a wildly successful marketing campaign?

• Who makes that call at your organization? A person? A system?

• And most importantly - would your customers even notice?

Would love to hear how you're thinking about this.

Haim

Here's the short version: it's not Shadow AI, where employees use tools nobody approved. This is the opposite. The organization approved everything - the tool, the deployment, the user. The problem starts after that, when the approved agent starts operating in ways nobody expected, with access to real systems and sensitive data.

To understand how big this actually is, it's worth looking at Gartner's research:

• By 2028, the average Fortune 500 enterprise is expected to run more than 150,000 AI agents

• Only 13% of organizations believe they have the right governance in place to manage them

• Gartner predicts 50% of AI agent deployment failures will come from inadequate governance and interoperability, not from the technology itself

That's the gap in one sentence: In the AI era approval isn't scaling at the same pace as deployment. Every agent that gets a green light isn't a box you check once - it needs ongoing visibility.

Have you heard of a case - not necessarily in your own organization - where an approved AI tool ended up accessing something it shouldn't have? What did you learn from it?