Searcharxiv⌕ Search
Home/Archive/arXiv

arXiv · 2610.33753

Ring-0 by Default: Agents as Operating Systems (AaOS)

Xiang Li·Aichun Huang·Zuyao Xu·Fasheng Miao·Zheli Liu
View original source ↗Read source document ↗Export metadata ↓

Abstract

LLM agents now read and write files, start processes and subagents, fetch network content, load third-party extensions, and save and resume state, which are the responsibilities of an operating system. They gained these functions within about three years, but not the protections that operating systems built over five decades: whatever the model outputs, whether it follows the user, a tool result, or a downloaded skill, runs with the full authority of the host user, in effect at ring 0. Prior work builds an operating system for agents (OS4A); we argue that a deployed agent already is like an operating system (AaOS) and analyze it as one. Taking the mechanisms of standard OS textbooks as a checklist, we map 116 mechanisms in 19 subsystems to their agent counterparts, from product documentation, source code, and the literature, and label each as isomorphic, degraded (function present, protection dependent on the model), missing, mutated, or novel. Only 11 are isomorphic and 65 are missing, most of them protections: privilege separation, resource quotas, transactions, and tamper-proof audit. Existing defenses confine the whole agent or review its extensions and leave this interior unprotected, and by Anderson's reference-monitor criteria (non-bypassable, tamper-proof, verifiable), rules written in the prompt satisfy none. We test the map with thirteen experiments on Claude Code, Codex CLI, and Gemini CLI, covering 25 mechanisms whose enforcement documentation cannot settle: 16 match the analysis, 7 gain a more precise description, and 2 change verdict. Checks sit in single tools, so the shell bypasses them; all three CLIs load forged transcript records on resume; and task control, sub-agent permissions, and model-based monitors are weak. We identify five problems for which no OS defense transfers and derive a prioritized list of open problems from the gaps of the map.

Explore related subjects

cs.CRcs.OS

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Xiang Li, Aichun Huang, Zuyao Xu, Fasheng Miao, Zheli Liu. 2026-10-24. Ring-0 by Default: Agents as Operating Systems (AaOS). https://arxiv.org/abs/2610.33753

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

arXiv2026

What's in a Package? Getting Visibility Into Dependencies Using Security-Sensitive API Calls

The Log4Shell vulnerability occurred because the JNDI (Java Naming and Directory Interface) lookup feature was used, even though it was not needed for log4j's core functionality. This case illustrates why developers may want visibility into the sensitive capabilities available through a dependency. The presence of a call alone does not establish that the call is unnecessary or risky. Security-sensitive APIs provide access to security-sensitive resources, such as filesystem, network, or process-related resources. If developers know which types of sensitive resources a dependency can access, they can control their dependencies at a finer grain, and they can consider an alternative dependency when a dependency makes unnecessary or suspicious security-sensitive API calls. However, prior work has not provided a documented, repeatable procedure for deriving an ecosystem-specific security-sensitive API list, so developers lack systematic visibility into the sensitive capabilities of their dependencies. The goal of this study is to aid developers in understanding sensitive resources accessible to their dependencies by identifying security-sensitive APIs in packages through an empirical study of Java packages. In this study, we present a novel and repeatable methodology to construct a security-sensitive API list for an ecosystem, and we apply it to Java. We then compare the security-sensitive API calls of functionally similar Java packages. The number of security-sensitive API calls (call level) ranges from 0 to 368 in one capability and from 0 to 429 in total among packages with similar functionality. These packages also differ in capability breadth, the number of the 15 capabilities that a package reaches. For example, capability breadth ranges from 0 to 10 in the "Dependency Injection" category and from 0 to 13 in the "Web Frameworks" category.

cs.CR↗
arXiv2026

WADBERT: Dual-Channel Web Attack Detection via Permutation-Invariant Parameter Modeling

Web attack detection is the first line of defense for securing web applications, designed to preemptively identify malicious activities. Deep learning-based approaches are increasingly popular for their advantages: automatically learning complex patterns and extracting semantic features from HTTP requests to achieve superior detection performance. However, existing methods are less effective at representing irregular HTTP requests and introduce unnecessary sensitivity to payload parameter order. To tackle this issue, in this paper, we propose WADBERT, a structure-aware dual-channel framework for web attack detection built on two complementary designs. First, we introduce \textit{Hybrid Granularity Embedding (HGE)}, which combines WordPiece embeddings with token-aligned character representations to capture fine-grained patterns in symbol-dense URLs and payload parameters. Second, we develop \textit{structure-aware feature extraction}, with separate branches for the sequential URL and the unordered collection of payload parameters. Each parameter is encoded independently, and position-free multi-head attention followed by mean pooling produces a payload representation invariant to parameter reordering. The URL and payload features are fused for request classification, while the learned parameter-level attention weights support inspection of potentially malicious parameters. Experiments on CSIC2010 and SR-BH2020 validate the effectiveness of our method: WADBERT achieves F1-scores of 99.64\% and 99.59\%, respectively, outperforming the evaluated state-of-the-art baselines.

cs.CR↗
arXiv2026

A Cross-Modal Prompt Injection Attack against Large Vision-Language Models with Image-Only Perturbation

Large vision-language models (LVLMs) have emerged as a powerful paradigm for multimodal intelligence, but their growing deployment also expands the attack surface of prompt injection. Despite this growing concern, existing attacks still suffer from a critical limitation: the injected prompt for one modality only steers the model's interpretation of that singular input. Alternatively, these attacks remain multimodal but fail to achieve cross-modal prompt perturbation. To bridge this gap, we introduce a novel cross-modal prompt injection attack CrossMPI, which can steer the model's interpretation of both textual and visual inputs via image-only prompt injection. Our design is underpinned by the following key breakthroughs. First, we turn the focus of the injected prompt perturbation optimization from the visual embedding space (typically with only $10^5$ parameters) to the model hidden state space (for multimodal information integration and with $10^7$ parameters). Then, two strategies are adopted to mitigate the optimization challenges posed by the larger parameter space. To constrain the optimized model parameter space, we introduce a layer selection strategy that identifies the layers most critical to multimodal integration. Interestingly, deviating from the past experience, our analysis reveals that the optimal layers for LVLM prompt perturbation reside in the middle of the model rather than the last. To constrain the image perturbation space, we propose a new distance-decremental perturbation budget assignment strategy that allocates budgets decrementally as the pixel distance to semantic-critical regions increases. Extensive experiments across multiple LVLMs and datasets show that our method significantly outperforms baseline approaches.

cs.CR↗