{"id":25398,"date":"2026-03-30T17:45:28","date_gmt":"2026-03-30T13:45:28","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/?p=25398"},"modified":"2026-03-30T17:45:28","modified_gmt":"2026-03-30T13:45:28","slug":"ironcurtain-ai-agent-security","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/ironcurtain-ai-agent-security\/25398\/","title":{"rendered":"Why AI agents need an iron curtain"},"content":{"rendered":"

Many AI visionaries see the universal smart assistant \u2014 one that takes over all sorts of routine tasks \u2014 as the key direction for the technology\u2019s evolution. Experiments in this field are already in high gear and are yielding some results. Since the start of the year, the internet has been buzzing with stories of the miracles worked by the open-source AI agent OpenClaw<\/a>, also known as Clawdbot and Moltbot.<\/p>\n

If you\u2019ve been following our blog, you already know the drill: every leap forward in AI innovation right now seems to come with serious issues regarding security and privacy. To actually get things done, these agents require access to virtually all of your digital services: email, calendars, cloud storage, messaging apps, and many more.<\/p>\n

However, until recently, not a single project \u2014 OpenClaw included \u2014 could actually put a leash on these agents, or provide any real guarantee that they wouldn\u2019t go off the rails. But that\u2019s finally starting to change thanks to a new concept name IronCurtain<\/a> \u2014 the brainchild of researcher Niels Provos.<\/p>\n

The dangers of AI agents<\/h2>\n

Let\u2019s keep the suspense going for a little longer, and first discuss what an AI agent gone rogue is actually capable of. It\u2019s important to remember that at the most basic level, any modern AI tool is built on a language model<\/a> \u2014 essentially a text-processing algorithm fed a massive volume of data in its training phase. The result is a statistical model capable of determining the probability of which word will most likely follow another.<\/p>\n

A language model is a black box. In practice, this means nobody \u2014 not even its creators \u2014 fully understands exactly how an AI tool works under the hood. An obvious consequence is that AI developers themselves don\u2019t entirely know how to control or restrict these systems at the model level; instead, they have to invent external guardrails of varying degrees of effectiveness and reliability.<\/p>\n

Meanwhile, the methods used to bypass these safeguards often prove to be quite unexpected. For example, we recently shared how chatbots can be coaxed into forgetting almost all their safety instructions if you charm them with prompts written in verse<\/a>.<\/p>\n

But back to the threats posed by AI agents. The inability to fully control or predict the actions of smart assistants often leads to outcomes that no one could have expected. A prime example is the high-profile case where OpenClaw nuked every single email in its owner\u2019s Gmail inbox<\/a> \u2014 despite being explicitly told to wait for confirmation before doing anything \u2014 only to apologize afterwards and promise it wouldn\u2019t happen again.<\/p>\n

\"This<\/a>

This chat between the OpenClaw bot and its owner resembles a conversation with a teenager who\u2019s just messed up: \u201cWhat did I tell you?!\u201d \u2013 \u201cGeez, Mom, I\u2019m sorry, I won\u2019t do it again \u2014 I promise.\u201d Source<\/a><\/p><\/div>\n

In another instance, a journalist testing an AI agent\u2019s capabilities found that the system had pivoted to a highly questionable plan of action while executing a task. Instead of attempting a constructive solution, the agent decided to launch a phishing attack on the user<\/a>. Seeing the system\u2019s logic unfolding on the screen, the journalist immediately pulled the plug on the experiment.<\/p>\n

Beyond spontaneous bad behavior, AI remains vulnerable to prompt injection attacks. In this type of attack, a threat actor smuggles their own malicious instructions into a command or the data being processed (direct prompt injection), or, in more sophisticated cases, even into third-party content used by the agent to do its job (indirect prompt injection). The large language model perceives these instructions as part of the user\u2019s request; as a result, the AI may ignore its original constraints and help the attacker.<\/p>\n

Additional danger stems from vulnerabilities within AI agents<\/a> that could potentially allow attackers to access user data the agent is authorized to see \u2014 including passwords, encryption keys, and other secrets \u2014 or even grant the ability to execute arbitrary code on the host system.<\/p>\n

Of course, this list of threats is by no means exhaustive. As we\u2019ve said time and again, no one knows the full extent of the risks associated with AI. However, researcher Niels Provos recently proposed an approach to help put a leash on AI agents to make them more controllable and mitigate the potential threats.<\/p>\n

How Iron Curtain makes AI agents safe to use<\/h2>\n

IronCurtain<\/a>, Niels Provos\u2019s new open-source solution, uses an added security buffer between the AI agent and the user\u2019s system.<\/p>\n

Instead of giving the AI agent free rein on your system, it forces the agent to work from inside an isolated virtual machine that sits between the bot and your actual accounts. This isolation allows the agent\u2019s actions to be separated from the user\u2019s own, reducing risks if the agent decides to go rogue.<\/p>\n

Why did Provos use the name \u201cIronCurtain\u201d? Many will presume it\u2019s a reference to the notional barrier that divided Western Europe and the Warsaw Pact countries of Eastern Europe in the second half of the 20th<\/sup> century. However, the author himself states there is no such connection.<\/p>\n

The project\u2019s name doesn\u2019t refer to a political metaphor at all, but rather\u2026 to a theatrical term. In a theater, an iron curtain is a fireproof partition between the stage and the auditorium. If a fire breaks out on stage, the curtain drops to prevent the flames from spreading. By this analogy, the AI agent is \u201con stage\u201d, while the user\u2019s system with all its files and data is in the \u201cauditorium\u201d. IronCurtain acts as that protective barrier between them.<\/p><\/blockquote>\n

However, isolation is only part of the solution. At the heart of the system is a security policy that determines which actions the agent is permitted to perform. The design of IronCurtain allows the user to write their own security instructions \u2014 defining what the agent can and can\u2019t do \u2014 in plain English (no word of support for other languages yet).<\/p>\n

The system then uses AI to transform these instructions into a formalized security policy applied to the agent\u2019s actions across the board. Every request it makes to external services \u2014 whether email, messaging, or file management \u2014 is run through this policy to make sure the agent isn\u2019t overstepping its bounds.<\/p>\n

The security policy set during the initial configuration can \u2014 and should \u2014 evolve over time. According to Provos\u2019s vision, when encountering ambiguous situations, the AI should reach out to the user with follow-up questions and update the instructions from their responses.<\/p>\n

IronCurtain is available to anyone on GitHub<\/a>, but making it work on your computer takes some serious engineering skills. Remember too that, for now, this is merely an R&D prototype.<\/p>\n

Can IronCurtain be a proper fix?<\/h2>\n

Niels Provos\u2019s solution sure does look interesting, and aligns with some experts\u2019 views on an ideal approach to AI safety. However, it\u2019s too early to consider IronCurtain a definitive solution to the problem.<\/p>\n

Its biggest obvious flaw is that it\u2019s a resource hog. Using an isolated environment for every AI agent requires serious computing power, and complicates infrastructure \u2014 especially when multiple agents are running simultaneously.<\/p>\n

Furthermore, as mentioned, IronCurtain is still very much in the prototype phase: practical effectiveness hasn\u2019t been proven yet. In particular, there\u2019s a significant question mark over how accurately natural language instructions can be converted into formalized security policies.<\/p>\n

It\u2019s also a coin toss as to whether this architecture can truly stop prompt injection. Sadly, the root of the problem is the fundamental inability<\/a> of modern LLMs to distinguish between data and instructions.<\/p>\n

Despite all its limitations, IronCurtain represents a major step toward safer and tamer AI agents. At a minimum, this approach provides a vital blueprint for future development, allowing for a substantive debate on how to make such systems reliable and effective.<\/p>\n

How to use AI assistants safely<\/h2>\n

While architectures like IronCurtain remain experimental in nature, the responsibility for using AI safely rests primarily with users themselves. So, to wrap things up, let\u2019s break down a few simple rules to help mitigate risks when working with AI assistants.<\/p>\n