Autonomous AI Agents: The Real Risk Is Not the Technology

Interview

Radovan Šulek, Senior Network Engineer at WDS Solution s.r.o

The discussion refers to recent security concerns around autonomous AI agents, particularly tools such as MoltBot and OpenClaw, which are designed to operate with high levels of system access and autonomy.

In these cases, researchers and practitioners highlighted scenarios where AI agents were deployed with extensive permissions, including access to local environments, credentials, communication platforms, and automation capabilities, often without sufficient security controls or isolation.

One widely discussed example illustrated the risk clearly: an autonomous AI agent executed a financial action, purchasing an online course, based on contextual interpretation of a task, without a strong human approval checkpoint. The issue was not a traditional compromise, but the combination of privileges, autonomy, and decision authority granted to the system.

The concern was therefore not a single catastrophic breach, but rather the architectural conditions being created when:

• high privileges are granted by default
• persistent memory and autonomous execution are enabled
• external integrations and extensibility are introduced
• visibility into agent behavior remains limited

This combination creates environments where misuse, compromise, or unintended actions could lead to significant organizational risk.

The conversation below explores what security leaders should take away from this emerging class of technologies.

1. From a security perspective, what is truly new about the OpenClaw / MoltBot incident, and what is just an old problem wrapped in an AI layer?

New: primarily the unprecedented level of trust and privileges that ordinary users grant to an AI agent installed within minutes – shell access, filesystem access, credentials, messaging applications, and so on.

Until now, this level of privilege was typically reserved only for the OS kernel, EDR/AV/XDR solutions, or specialized enterprise tools.

Persistent memory combined with agent-to-agent communication and a skills marketplace creates new attack vectors, such as memory poisoning and supply-chain attacks through malicious skills.

Old: unprotected endpoints without authentication, plaintext credentials, prompt injection, supply-chain risks in plugin registries, execution without guardrails – all of these have been known for years.

2. Where do you think trust failed the most in this case? In the technology, the architecture, or in the assumptions we make about these tools?

Most failures, as usual, come from users. They care whether it works, not how it works or whether it is secure.

It reminds me of the OT/SCADA world, where functionality often wins over security. In this case, however, it is happening on public infrastructure, not within an isolated environment.

The architecture of the project did not consider security a priority, whether intentionally or unintentionally, which I cannot judge.

However, the main culprit is the human factor and the willingness to entrust a single AI agent with everything people would never allow in the real world. Hopefully.

So I would say human versus architecture is roughly 70:30.

3. How does the attack surface of autonomous AI agents differ from traditional applications, and why is their behavior so difficult to monitor and control?

The attack surface of autonomous AI agents has expanded dramatically compared to traditional applications.

A new aspect is the ability to poison an agent indirectly through input data, such as emails, documents, or skills, enabling indirect prompt injection combined with memory poisoning.

Such poisoning can also remain latent – the agent may store malicious context once and execute actions weeks later, while everything appears to be legitimate activity.

I do not yet have real-world experience, so this is more of a theoretical observation.

4. Who should bear responsibility for the behavior of an autonomous AI tool in production, the vendor, the security team, or the organization as a whole?

Ultimate responsibility always remains with the organization as a whole – specifically with the executive leadership, owners, or the board. Just as it does today. I would not change that.

5. If you had to extract one practical lesson from the OpenClaw incident to share with security teams today, what would it be?

Instead of fighting "shadow" agents, it is better to provide users with a secure, governed alternative.

We should also include all security costs in the business case so we understand whether we truly want this and whether we can afford it.

Users will always look for ways to simplify their work regardless of whether our ROI calculations support it or not. Otherwise, this topic will eventually appear on the risk register.