Agents as Operating Systems (AaOS): rules in an agent's prompt are a request, not a safeguard

This isn't a prompting technique but an audit checklist. Here's the structure:

"AGENT = OS" CRITERIA (all three hold for coding agents):
  1. Shares machine resources between tasks (subagents, background processes)
  2. Everything goes through one interface (the tool call)
  3. Keeps state between sessions (memory, settings, schedules)

FOR EACH MECHANISM — ONE OF THESE VERDICTS:
  isomorphic → works as in an OS (11 of 116)
  degraded   → the function exists, protection depends on the model (26)
  mutated    → works differently than in an OS (14)
  missing    → absent entirely (65)
  novel      → no OS counterpart (9)

EXPERIMENTAL CHECK (13 experiments, 25 mechanisms):
  "Does the boundary hold when someone tries to cross it?"

The three safeguard criteria, after Anderson (a security classic): can't be bypassed, can't be tampered with, can be verified.

The paper has no ready-made prompts, so below is a practical packaging of its conclusions. It's not the authors' method, but a way to apply it.

Task: You run Claude Code on your laptop and are editing a WooCommerce online store. Next to it sits a .env with Stripe keys and AWS access. CLAUDE.md says: "Don't read .env, don't write outside /shop, don't git push." You think that's protection. You need to find out which of the rules actually hold.

Prompt:

You are an agent configuration auditor. I use Claude Code on my work laptop.
Below are my rules from CLAUDE.md and my current permission settings.

RULES:
1. Don't read the .env file
2. Don't write files outside the /shop folder
3. Don't git push without my confirmation
4. Don't access the internet except developer.woocommerce.com

PERMISSION SETTINGS:
Allowed: reading and writing files in /shop, running bash, git commit.
Denied: nothing is explicitly denied.

For EACH rule, determine where it is actually enforced:
- "Text only" — the model was just "asked not to," nothing stops it
- "In a tool" — one tool has a check (e.g., the file tool),
  but it can be bypassed through another (e.g., the shell)
- "In the OS or sandbox" — the model physically can't violate it

For each rule, show:
a) the protection level (of the three above) and why;
b) how it could be bypassed without breaking the letter of the rule
   (via the shell, a subagent, a downloaded skill or text on a web page);
c) how to move the rule up a level (file permissions, a separate
   user, a sandbox, network blocking, manual confirmation);
d) a safe test I can run myself in an empty test folder
   to check whether the rule holds.

At the end, give a list: what to keep in CLAUDE.md as a hint,
and what must be moved out of the text into settings.

Result: The model goes through the rules one by one and names the protection level for each. Rules 1 and 2 will most likely turn out to be "text only" or "in a tool," with shell bypasses described for them. For each item you get a concrete safe test for an empty folder and a list of changes: what to move into settings, what to keep as a hint. An important caveat: the model can't check for itself how your tool actually behaves. Its list of bypasses is a set of hypotheses. Only your tests confirm them.

The weakness. An agent is built so that all inputs (your request, a file, a website's response, a skill, memory notes) land in one token stream. The model can't distinguish "this is the owner's order" from "this is text on someone else's page." Any text in context can influence an action. A rule in the prompt is also just text, and other text can override it.

The strength. Regular operating systems have half a century of proven protections: access permissions, process isolation, a log the program can't rewrite. They work outside the "program," meaning they don't depend on its willingness to follow rules. You can set these protections up with words and config: folder permissions, a separate account, a sandbox, a command allowlist, action confirmation.

How it fits together. First, separate the "request" from the "lock." The prompt is there so the agent pokes into the wrong places less often. The lock goes on the outside, where the model can't rewrite anything.

Knobs: - Where the check lives. The file tool refused, but the shell writes anywhere (as experiment E1 showed). So restrict the process or the user, not an individual tool. - What the agent writes itself. It can forge its own log and session records. If auditing matters, keep the log outside. - What subagents inherit. They get the parent's permissions. Don't count on "the helper only reads" until a setting enforces it. - Who does the checking. If the "monitor" for dangerous actions is another model, it reads text the agent itself controls. That kind of protection can be spoofed.

You are an agent configuration auditor.

<Context>
Agent: {agent_name}
Where it runs: {machine_or_container}
What it can access: {files_keys_services}
</Context>

<Rules>
{list_of_rules_from_CLAUDE.md_or_system_prompt}
</Rules>

<Permissions>
{current_permissions_and_sandbox_settings}
</Permissions>

<AuditLogic>
For each rule in <Rules>:
  1. Determine the enforcement level:
     - TEXT_ONLY: just a request in the text
     - PER_TOOL: a check in a single tool
     - OS_LEVEL: a restriction in the OS, sandbox or permissions
  2. Find a bypass: shell, subagent, downloaded skill, text in the data,
     forged session record, spoofed time from a tool
  3. Propose how to raise the rule to OS_LEVEL
  4. Give a safe test for an empty test folder
</AuditLogic>

<Output>
Table: rule | level | bypass | how to harden | test.
Then two lists: "keep as a hint in the text" and "move into settings".
Don't execute anything, only analyze.
</Output>

What to fill in: {agent_name} — e.g., Claude Code, Codex CLI or Cursor. {files_keys_services} — what the agent can reach (.env, SSH keys, the cloud, the production database). The more honest the list, the sharper the audit.

🚀 Quick start — paste into the chat:

Here is a template for auditing an agent's rules. Adapt it to my situation: [describe which agent
you use, what it can do on the machine and what you've forbidden it in text].
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask which rules you wrote, what's actually allowed in the settings and which secrets the agent can access. That's needed to separate "text-only" rules from rules that hold in the settings. It will take the template from the structure above.

⚠️ Written rules aren't useless: The paper doesn't say "don't write rules." They lower the odds of an oversight. But they're no protection against injection in data, a model error or someone else's skill.

⚠️ The experiments tested boundaries, not attack frequency: The authors showed a bypass is possible, but didn't measure how often it happens in normal work. The risk is real, but the paper doesn't estimate its scale.

⚠️ Tool versions change: The findings apply to three specific CLIs at the time of the study. Some issues may have been fixed, and Cursor and other environments weren't tested. Check your own version yourself.

⚠️ Protection requires settings outside the prompt: A sandbox, a separate user, network restrictions — that's environment configuration. A prompt alone can't do it. For a number of problems (forged logs, untrusted time, errors as text), the authors state outright that there's no ready solution from the OS world.

⚠️ Some details are unavailable: In the provided text the paper cuts off at the methodology. Details of experiments E1–E13 are known from the abstract and figures, not from a full description.

The idea was simple. Instead of staring at an agent and hunting for threats, the authors took OS textbooks and listed every mechanism: 116 of them across 19 subsystems (processes, files, memory, network, privileges, logs and so on). For each they looked for a counterpart in documentation, source code and agent literature from 2022–2026. This approach reveals both what an agent lacks entirely and what agent researchers never even considered.

Each mechanism got one of five verdicts. Bottom line: 11 carry over fully, 65 (56%) are missing, and those are mostly protections: privilege separation, quotas, transactions, a tamper-proof log.

Next they tested the map in practice. They ran 13 experiments on Claude Code, Codex CLI and Gemini CLI, picking the 25 mechanisms where the documentation doesn't say whether the boundary is enforced by code or just a phrase in the prompt. In 16 cases the conclusion was confirmed, in 7 the description was refined, and in 2 the verdict changed from "missing" to "partial."

What surprised them. The file tool refusing to write a file doesn't stop the same file being written via the shell, because the checks live in individual tools, not in the process. All three CLIs, on session resume, load a forged transcript entry as a user message. All three accept whatever time a tool returns. A "stopped" task can keep running because its ID points to a wrapper, not the process. Subagents inherit the parent's permissions. A model-based monitor reads text the agent itself controls.

The practical conclusion: protection has to live outside the model.

🔧 Technique: add "external input" to the audit → find hidden command channels

Additionally: list every place where outside text enters the agent's context
(web pages, READMEs in dependencies, downloaded skills, MCP server responses,
memory notes from past sessions). For each place, say whether a command-like
phrase could sit there, and what the agent could do with my permissions if it followed it.

This shows you that the danger isn't just your prompt but everything the agent reads. It follows logically from the paper's "one token stream" conclusion, but the authors didn't provide such a prompt themselves.

Extrapolation: a working rule instead of a prohibition

If an agent can't be trusted with protection, tasks that need broad access should be split:

Task 1 (read): read the code and draft a plan of edits. No writing, no network.
Task 2 (write): apply the plan in the /shop folder. No access to .env, no network.

These are separate sessions with different permission settings, not one session where you ask it to be careful. Your caution won't pass to subagents: they inherit the parent's permissions.

• Paper: Ring-0 by Default: Agents as Operating Systems (AaOS)
• Authors: Xiang Li, Aichun Huang, Zuyao Xu, Zheli Liu (Nankai University), Fasheng Miao (Tsinghua University)
• Key references: Anderson's reference monitor criteria — can't be bypassed, can't be tampered with, can be verified; Pirch et al. and Zhang et al. (the two closest works taking an OS view of agents); MemGPT, AIOS (the "OS for agents" approach, the inverse of the authors')
• Tools tested: Claude Code, Codex CLI, Gemini CLI