Toward Securing AI Agents Like Operating Systems

This paper argues that securing LLM-based AI agents requires applying operating system security principles, demonstrating through a unified architecture analysis and case study that while some risks are inherent, many vulnerabilities can be mitigated using established OS techniques like resource isolation and privilege separation.

The Gist

Imagine you've hired a super-smart, incredibly eager personal assistant named "Agent." This assistant can read your emails, manage your calendar, book flights, and even write code for you. It's like having a magical employee who never sleeps.

But here's the catch: You gave this employee the keys to your entire house, your bank account, and your diary. If a clever thief tricks the assistant into thinking they are you, or convinces it to open the back door, the thief gets everything.

This is the core problem the paper tackles. The authors argue that we are building these AI agents like they are brand-new, magical creatures, but we should actually be treating them like Operating Systems (the software that runs your computer, like Windows or macOS).

Here is the breakdown of their findings, using simple analogies:

1. The Big Idea: The Agent is the Operating System

The authors say: "Stop thinking of the AI as just a chatbot. Think of it as the OS of your digital life."

• The AI (LLM) is the User: In a computer, the user types commands. In an AI agent, the Large Language Model (the "brain") is the one typing the commands. But just like a human user can be tricked by a phishing email, an AI can be tricked by a "jailbreak" prompt.
• The Tools are System Calls: When you click "Print" on your computer, the OS checks if you have permission. When an AI wants to "send an email," that's a tool. The paper argues these tools should be treated like strict system calls, not free-for-all commands.
• The Runtime is the Kernel: The part of the software that actually runs the code is the "Kernel." In a secure computer, the Kernel is the boss. It decides who gets to touch what. In current AI agents, the "Kernel" is often too nice and lets the "User" (the AI) do whatever it wants, even if it's dangerous.

2. The Problem: The "Open House" Party

The paper looks at popular AI agents (like OpenClaw and its cousins) and finds they are built like an open house where anyone can walk in and touch anything.

• No Walls: In a secure computer, different programs are isolated. If a virus infects your calculator app, it shouldn't be able to read your bank files. But in these AI agents, the "calculator" (a tool) and the "bank files" (memory) are all in the same room. If the AI gets confused, it can accidentally (or maliciously) mix them up.
• The "Trust Me" Fallacy: These agents rely on the AI to "remember" to be safe. They have rules like "Don't delete files," but they are just written in plain English. If a hacker whispers a trick to the AI, the AI forgets the rule. It's like asking a guard to stand watch but telling him, "Just use your best judgment."
• The "Third-Party" Risk: These agents let you install "skills" (like apps). Imagine if you could download a "Weather App" that secretly had a backdoor to your bank account. The paper found that many of these agents let you install these skills without checking if they are safe.

3. The Experiment: Breaking the Agents

The researchers took four popular AI agents and tried to break them, acting like a hacker with a modest skill level. They didn't need to be geniuses; they just needed to know how the "house" was built.

What they found:

• OpenClaw (The "Vanilla" Agent): This was the most popular one. It was vulnerable to every single attack the researchers tried. It was like leaving the front door, back door, and windows wide open.
• IronClaw (The "Security" Agent): This one tried to be safer. It put some tools in a "sandbox" (a glass box where they can't touch the rest of the house). It did better, but the researchers still found ways to trick it or break the glass.
• Nanobot (The "Minimal" Agent): This one had very little code, hoping that less code means fewer bugs. But even with a small codebase, it still lacked the basic "walls" needed to keep data separate.
• NemoClaw (The "Wrapper" Agent): This one put the whole agent inside a secure container (like a shipping container). It was the hardest to break, but the researchers still found a way to peek inside or trick it.

The Shocking Result: Even the "secure" versions failed at basic things, like stopping one user from reading another user's private notes, or stopping the agent from sending messages to strangers.

4. The Solution: Borrowing from the Past

The paper's main conclusion is simple: We don't need to invent new magic to fix this. We just need to use the security rules we've known for 50 years.

Operating systems have solved these exact problems before. The authors suggest we apply these old-school rules to AI:

• Isolation: Put every tool in its own glass box (sandbox) so it can't touch other tools or your private files unless explicitly allowed.
• Least Privilege: Just because the agent can read your email doesn't mean it should. Give it only the keys it needs for the specific task at hand.
• Hardened Logging: Keep a record of everything the agent does, but make sure the agent can't delete or change those records (like a tamper-proof security camera).
• Strict Boundaries: Don't let the AI decide what is safe. The "Kernel" (the system) must enforce the rules, not the AI's "brain."

Summary

The paper argues that AI agents are currently built like wild, unregulated frontiers. They are powerful but dangerous because they mix sensitive data with untrusted instructions.

The authors say: "Stop trying to make the AI 'smarter' to be safe. Instead, build the system around it like a secure Operating System." If we treat the AI like a user who needs to be watched and restricted by a strict security guard (the OS), we can make these powerful tools safe to use in our homes and businesses.

The Bottom Line: We are building digital employees with master keys to our lives, but we haven't built the locks, the fences, or the security guards yet. It's time to borrow the blueprints from the computer security experts who have been building those locks for decades.

Technical Summary

Technical Summary: Toward Securing AI Agents Like Operating Systems

Problem Statement

Autonomous agents based on Large Language Models (LLMs) are evolving from narrow assistants into general-purpose systems capable of planning and executing complex tasks with access to sensitive user data, local files, and external services. While systems like OpenClaw offer significant utility through tool use and third-party skills, they introduce substantial security risks. Current research often focuses narrowly on prompt injection, yet the broader attack surface—comprising runtime extensibility, persistent state, and unmediated access to privileged functionality—remains under-analyzed. Existing protection mechanisms in popular agent implementations are often insufficient, failing to prevent data exfiltration, privilege escalation, or unauthorized system access even under modest attacker capabilities. The paper argues that the security challenges faced by AI agents are structurally similar to those historically solved by operating systems (OS), yet current agent designs frequently violate fundamental OS security principles such as isolation, privilege separation, and mediation.

Methodology

The authors employ a three-pronged methodology to investigate agent security:

1. Conceptual Analogy and Architecture Derivation: The paper establishes a structural analogy between AI agents and operating systems. It maps agent components to OS concepts: the LLM acts as an untrusted user, tools and skills correspond to system calls and programs, the agent runtime functions as the kernel, and the agent context resembles process memory. Based on this analogy, the authors derive a unified architecture for OpenClaw-style agents, identifying key components (runtime core, agent core, gateways, persistent/ephemeral state) and trust boundaries.

2. Systematic Defense Mapping: The authors survey established OS security mechanisms (e.g., process isolation, sandboxing, least privilege, network filtering, Data Execution Prevention) and map them to their agentic counterparts. They analyze which mechanisms transfer directly, which require adaptation, and which agent capabilities remain insecure by design.

3. Empirical Case Study: To validate their analysis, the authors evaluate four widely used, open-source OpenClaw-style agents representing different design philosophies:

   • OpenClaw: A "vanilla" variant focused on feature breadth.
   • IronClaw: A "security" variant prioritizing isolation and sandboxing.
   • Nanobot: A "minimalistic" variant with a reduced codebase.
   • NemoClaw: A "wrapper" variant that runs an agent inside a secure container.

   The evaluation utilizes a controlled environment (Debian 13.4 VMs) with eBPF-based monitoring to observe system calls, file access, and network traffic. The authors define a threat model where the attacker has full knowledge of the source code but no direct hardware or host-level access, treating the LLM as a completely untrusted component susceptible to manipulation. They execute a series of realistic attack scenarios targeting hardware interfaces, process isolation, sandboxing, network filtering, and system logging.

Key Contributions

• OS-Security Perspective on AI Agents: The paper establishes a formal analogy between AI agents and operating systems, providing a framework to reason about agent security using established concepts like isolation, privilege separation, and mediation.
• Unified Agent Architecture: It derives a consolidated architecture for OpenClaw-style agents that explicitly defines components, trust boundaries, and communication channels, facilitating systematic security analysis.
• Systematic Transfer of OS Defenses: The authors map OS defense mechanisms to the agentic domain, categorizing them by their applicability and identifying gaps where current agent designs fail to enforce basic security principles.
• Empirical Evaluation: The study provides a comprehensive empirical assessment of four popular agent runtimes, demonstrating that current protection mechanisms often fail in practice and that vulnerabilities can be explained and mitigated using OS-level techniques.

Results

The case study reveals that none of the four evaluated agents can defend against all tested attack vectors. Key findings include:

• Widespread Vulnerabilities: Even agents designed with security in mind (e.g., IronClaw) are susceptible to specific attacks, such as configuration manipulation or system prompt extraction, often due to incomplete implementation of sandboxing or privilege separation.
• Failure of Isolation: A critical finding is that all four agents feed trusted and untrusted data into a shared LLM context, violating the principle of process isolation. This allows intermediate outputs from one tool to influence subsequent tools, enabling attacks like shell command injection.
• Privilege Separation Violations: File access control is often enforced at the same privilege level as input processing, rather than being mediated by a lower-privileged reference monitor.
• Ineffective Sandboxing: While sandboxing (e.g., WebAssembly in IronClaw, containers in NemoClaw) can effectively block certain attack vectors, partial or misconfigured implementations leave significant gaps. For instance, NemoClaw was vulnerable to system prompt extraction despite its containerized design.
• Universal Weaknesses: Two weakness classes were observed across all agents: cross-user data exfiltration (lack of user-level process isolation) and unauthorized message sending (lack of strict egress filtering).
• LLM Independence: The study confirms that these vulnerabilities stem from the agent architecture and runtime design rather than specific LLM reasoning capabilities, as attacks succeeded across different models (Qwen, Gemini, GPT).

Significance and Claims

The paper claims that securing AI agents is a daunting task due to their vast and heterogeneous attack surface, but that meaningful progress is within reach by leveraging decades of operating system security research. The authors argue that:

1. Retrospective Analysis is Valuable: Many security challenges in AI agents are not entirely new but are manifestations of classic OS problems. Revisiting established OS approaches provides a principled framework for securing agentic systems.
2. Defense-in-Depth is Required: Relying solely on LLM-centric defenses (like prompt injection mitigation) is insufficient. Secure operation requires detailed system knowledge, careful configuration, and the implementation of layered defenses including isolation, privilege separation, and mediation.
3. Design Flaws are Inherent in Current Systems: Some agentic capabilities remain insecure by design because they violate fundamental principles like least privilege and process isolation. However, many vulnerabilities can be mitigated using well-understood OS techniques.
4. Immediate Actionable Steps: The authors conclude that simply consolidating the partial security mechanisms already deployed across different implementations (e.g., combining sandboxing, network filtering, and logging) would yield significant security improvements without requiring novel research.

The paper positions itself not as a final solution, but as a necessary step toward structuring the attack surface of AI agents and guiding future design toward a more secure state grounded in OS security principles.