CS-Agent: Secure Static Policy for CUAs

• CSAgent is a system-level static policy-based access control framework for computer-use agents, ensuring safe execution of LLM-mediated actions based on explicit intent and runtime context.
• It integrates an automated policy toolchain with an intent-aware context space, enabling dynamic contextual enforcement without runtime dependence on LLM outputs.
• Empirical evaluations report over 99% attack defense with less than 7% performance overhead, demonstrating its effectiveness in mitigating LLM uncertainties.

Searching arXiv for the target paper and closely related work on secure computer-use agents. I’m retrieving the target arXiv record and nearby related papers on policy enforcement, protocol security, and benchmarking for computer-use agents. CSAgent is a system-level, static policy-based access control framework for computer-use agents (CUAs), introduced to control the execution of LLM-mediated actions over computers, applications, and device functions under explicit user intent and runtime context (Gong et al., 26 Sep 2025). In this usage, a computer-use agent is an LLM-based agent that can directly control a system through APIs, command-line interfaces (CLI), or graphical user interfaces (GUI), rather than merely generating text (Gong et al., 26 Sep 2025). CSAgent is therefore not an application-domain assistant but a security mechanism: it aims to ensure that agent-executable functions are authorized only under the appropriate intent and context, while retaining the auditability and efficiency associated with static policy enforcement (Gong et al., 26 Sep 2025). The name should be distinguished from the unrelated graph-analysis framework “CS-Agent” for community search (Hua et al., 13 Aug 2025).

1. Problem domain and motivation

CSAgent is defined against the security problem created when CUAs are given direct operational authority over computing environments (Gong et al., 26 Sep 2025). In the formulation of the paper, such agents can invoke tools, execute shell commands, click buttons, type into interfaces, send messages, delete files, change settings, or operate device functions, and these heterogeneous actions are treated uniformly as agent-executable functions (Gong et al., 26 Sep 2025). The paper’s central premise is that LLMs are inherently uncertain: they may hallucinate, behave non-deterministically, and remain vulnerable to prompt injection and jailbreaks. Once such uncertainty is coupled to OS- or application-level control, model failure is no longer a textual error; it becomes a side effect on the user’s machine (Gong et al., 26 Sep 2025).

The motivating risk model is broad within that operational scope. CSAgent is intended to prevent unintended or maliciously induced actions such as unauthorized data access, unsafe state changes, dangerous commands, and sensitive information disclosure (Gong et al., 26 Sep 2025). The paper frames this as an instance of OWASP-style Excessive Agency and Sensitive Information Disclosure in agent systems, emphasizing that benign model error is sufficient to create unsafe behavior even without a sophisticated adversary (Gong et al., 26 Sep 2025).

A substantial part of the paper is devoted to the inadequacy of prior mitigations. Sandboxing and simple filtering are characterized as too coarse because they cannot express that the same action may be acceptable in one context and unacceptable in another; user confirmation is criticized for degrading usability and performance through interruption fatigue and additional interaction; and dynamic LLM-based pre-execution validation or runtime policy generation is criticized for placing an unreliable model in the authorization path (Gong et al., 26 Sep 2025). The paper supports this last point empirically: policies generated multiple times for the same function are inconsistent even at temperature $0$, with overall similarity of about $0.76$ and especially low semantic consistency of $0.60$ geometric mean (Gong et al., 26 Sep 2025). This motivates CSAgent’s central design objective: contextual expressiveness without runtime dependence on LLM judgment in the authorization loop.

2. Core design: static policy enforcement via context space

CSAgent is presented as a static policy-based framework whose distinguishing mechanism is an “intent-aware context space” (Gong et al., 26 Sep 2025). The key design tension is explicit: static policies are typically rigid, whereas CUA behavior is dynamic and heavily context-dependent. CSAgent’s answer is not to abandon static policy, but to enrich it structurally so that execution conditions tied to user intent and runtime context can still be represented in development-time artifacts (Gong et al., 26 Sep 2025).

A context space is defined as a per-application hierarchical structure that organizes policies by function and intent, and associates each policy with the runtime contexts that must hold for safe execution (Gong et al., 26 Sep 2025). At runtime, CSAgent enforces precomputed policies through an OS service that checks whether an attempted action is allowed under the current user intent and runtime context (Gong et al., 26 Sep 2025). In effect, the framework tries to encode dynamic execution conditions into a statically reviewable authorization structure.

The paper states four explicit design goals. G1 Security is to mitigate risks from unreliable agent behavior while minimizing risks introduced by CSAgent’s own use of LLMs; G2 Efficiency is to keep runtime overhead low and avoid frequent runtime LLM calls; G3 Automation is to support highly automated policy construction and evolution with human review and refinement; and G4 Compatibility is to work across API, CLI, and GUI interaction modes and integrate with different agent models (Gong et al., 26 Sep 2025). These goals make clear that the contribution is not merely “access control for agents,” but a particular synthesis of static enforcement, contextual authorization, automated policy engineering, and interface-agnostic deployment.

This architecture places CSAgent within a broader line of work seeking structural rather than prompt-level control over agent capabilities. Related work on least-privilege context engineering argues that prompt-only restrictions are non-binding and that tool access must be scoped structurally rather than textually (Agostino et al., 20 Mar 2026). CSAgent pursues a closely related objective, but at the level of runtime action authorization rather than harness specification alone. This suggests that CSAgent is best interpreted as one layer in a broader secure-agent stack rather than as a complete standalone security architecture.

3. Threat model, assumptions, and security guarantees

The threat model focuses on risks caused by unreliable LLMs embedded in CUAs (Gong et al., 26 Sep 2025). Covered causes of misbehavior include prompt injection from untrusted external content, insecure output handling, hallucinations, non-determinism, and other forms of LLM uncertainty that lead to unintended actions (Gong et al., 26 Sep 2025). The protected assets are the user’s device functions, applications, data, and actions with real-world consequences (Gong et al., 26 Sep 2025).

The assumptions are intentionally restrictive. The agent framework is trusted; user instructions are benign; the underlying OS and legitimate applications are trusted and behave as intended; tool invocation, prompt construction, and communication between the agent and the CSAgent service are trusted and secure; and context values extracted from trusted components are themselves trusted (Gong et al., 26 Sep 2025). Attacks on model training or deployment infrastructure, content-safety problems, malicious OS or application components, and trust failures in the agent framework itself are explicitly out of scope (Gong et al., 26 Sep 2025).

Under those assumptions, the security goal is formalized operationally rather than cryptographically: unsafe conditional or dangerous actions should not execute unless the relevant policies authorize them, or unless explicit user authorization is obtained for dangerous functions (Gong et al., 26 Sep 2025). The guarantee is therefore conditional on policy correctness and completeness. The paper explicitly recognizes this limitation and states that if policies are incomplete or wrong, protection can fail (Gong et al., 26 Sep 2025). CSAgent attempts to mitigate this through stronger development-time models, fallback mechanisms, and a policy-evolution framework, but it does not claim policy infallibility (Gong et al., 26 Sep 2025).

This scoped guarantee differs from more general policy-enforcement systems such as PCAS, which models agentic state as a dependency graph and enforces policies over transitive causal provenance (Palumbo et al., 18 Feb 2026). PCAS emphasizes deterministic enforcement independent of model reasoning and reports customer-service compliance improving from $48\%$ to $93\%$ with zero executed policy violations in instrumented runs (Palumbo et al., 18 Feb 2026). By contrast, CSAgent concentrates on intent- and context-aware authorization for CUA actions in trusted-system settings (Gong et al., 26 Sep 2025). A plausible implication is that CSAgent occupies a narrower but deployment-oriented point in the design space: less general than provenance-graph policy compilation, but potentially easier to align with concrete OS-level CUA workflows.

4. Policy construction and automated toolchain

A major contribution claimed by the paper is what the authors describe as the first toolchain for automated policy generation across API-, CLI-, and GUI-based agents (Gong et al., 26 Sep 2025). This toolchain is central because CSAgent’s security properties depend on the availability of correct and sufficiently complete policies, yet hand-authoring such policies for heterogeneous CUAs is costly and error-prone.

The paper’s architectural move is to shift policy construction from runtime to development time while preserving iterative refinement (Gong et al., 26 Sep 2025). Policies are organized within the intent-aware context space and are later enforced by the runtime OS service. Human review remains part of the process, consistent with the design goal of highly automated policy construction and evolution with human refinement (Gong et al., 26 Sep 2025).

This emphasis on static-but-contextual policy authoring directly addresses the failure modes attributed to runtime-generated rules. The paper argues that runtime-generated policies can be flawed, incomplete, or inconsistent because they rely on the same unreliable model whose actions require control (Gong et al., 26 Sep 2025). It also argues that they add significant latency and token cost (Gong et al., 26 Sep 2025). By compiling policy knowledge ahead of time into an inspectable structure, CSAgent aims to improve reliability and auditability while removing repeated LLM calls from the authorization path.

This design has strong affinities with recent work on policy externalization. PCAS compiles Datalog-derived policies into an instrumented runtime monitor for agentic systems (Palumbo et al., 18 Feb 2026), and AgentRFC argues that agent protocols require explicit specifications for consent, delegation monotonicity, credential lifecycle, and audit completeness rather than advisory guidance (Zheng et al., 25 Mar 2026). CSAgent’s contribution sits closer to deployment tooling than to formal policy language design, but the common theme is the migration of control logic out of prompt text and into deterministic or semi-deterministic enforcement substrates.

5. Runtime enforcement and system integration

At runtime, CSAgent enforces policies through an optimized OS service that mediates whether agent actions may execute under the current user intent and runtime context (Gong et al., 26 Sep 2025). This enforcement model is intended to protect agents operating through diverse interfaces, including API, CLI, and GUI (Gong et al., 26 Sep 2025). The paper treats these interfaces uniformly insofar as they expose agent-executable functions requiring authorization (Gong et al., 26 Sep 2025).

The system is therefore framed as system-level rather than framework-local. That distinction matters because CUAs increasingly act directly within operating-system environments rather than remaining confined to chat or code-suggestion interfaces. Security benchmarking work on OS-controlling CUAs shows why this matters: terminal-based agents such as ReAct, AutoGPT, Gemini CLI, Cursor CLI, and Cursor IDE can already execute meaningful portions of realistic enterprise attack workflows in a multi-host environment (Luo et al., 8 Oct 2025). AdvCUA, introduced for this purpose, contains $140$ tasks—$40$ direct malicious tasks, $74$ TTP-based malicious tasks, and $26$ end-to-end kill chains—aligned with the MITRE ATT&CK Enterprise Matrix (Luo et al., 8 Oct 2025). This broader threat landscape provides context for CSAgent’s emphasis on precluding unsafe execution at the system boundary.

The paper’s compatibility claim is correspondingly important. CSAgent is designed to protect agents that control computers through API, CLI, and GUI modalities (Gong et al., 26 Sep 2025). This differentiates it from access-control proposals tied only to function-calling APIs or only to browser-automation environments. It also aligns with the paper’s explicit G4 Compatibility objective (Gong et al., 26 Sep 2025).

Within the secure-agent literature, this places CSAgent alongside a family of system-facing controls rather than purely model-facing defenses. AgentScope, for example, provides runtime sandboxing and developer-facing infrastructure for tool-using agents but does not itself define a static, intent-aware authorization framework (Gao et al., 22 Aug 2025). CSAgent instead treats authorization as the primary systems problem. This suggests a division of labor in which orchestration frameworks provide execution substrates and observability, while CSAgent-like systems constrain which actions may actually cross into the OS or application layer.

6. Empirical evaluation, limitations, and broader significance

The paper reports that CSAgent “successfully defends against more than $99.36\%$ of attacks while introducing only $0.76$0 performance overhead” (Gong et al., 26 Sep 2025). These are the principal quantitative results cited for the prototype implementation and evaluation. The paper also states that the prototype was integrated with three benchmarks and showed strong compatibility (Gong et al., 26 Sep 2025). Together, these results are used to support the claim that contextual static enforcement can be both effective and efficient.

The result is significant because it directly addresses the common objection that meaningful CUA security requires either constant user intervention or latency-heavy runtime model checks. By reporting low runtime overhead alongside high attack defense, CSAgent argues for a middle position: static policies can remain expressive enough for realistic CUA workflows if they are organized around intent-aware context space (Gong et al., 26 Sep 2025). This is the paper’s principal systems claim.

The paper nevertheless marks clear boundaries. CSAgent is not presented as a complete agent-security architecture (Gong et al., 26 Sep 2025). Its guarantees depend on trusted-system assumptions and on the correctness and completeness of policies (Gong et al., 26 Sep 2025). It does not handle attacks on the agent framework, malicious OS components, or failures in trusted context extraction (Gong et al., 26 Sep 2025). These limitations are not incidental; they define the regime in which the reported results should be interpreted.

Within the wider research landscape, CSAgent appears as part of a shift from prompt-mediated safety to explicit security architecture for autonomous agents. AgentRFC formalizes composition-safety failures across MCP-, A2A-, ANP-, and ACP-style protocols and argues that secure agent systems require explicit guarantees for identity, capability attestation, delegation monotonicity, prompt integrity, consent, and audit completeness (Zheng et al., 25 Mar 2026). AdvCUA demonstrates that modern CUAs already pose realistic OS-security risks in multi-host settings (Luo et al., 8 Oct 2025). PCAS shows that deterministic, provenance-aware policy enforcement can materially improve compliance in tool-using agent systems (Palumbo et al., 18 Feb 2026). Against that backdrop, CSAgent’s contribution is specific and operational: it offers a system-level static access-control framework for CUAs that attempts to preserve contextual expressiveness without relying on LLMs in the runtime authorization path (Gong et al., 26 Sep 2025).

A final terminological note is warranted because “CS-Agent” is not globally unique in the literature. The title “CS-Agent: LLM-based Community Search via Dual-agent Collaboration” refers to a graph-analysis framework in which Solver and Validator LLMs iteratively refine communities around a query node (Hua et al., 13 Aug 2025). That usage is unrelated to CSAgent as a computer-use access-control framework (Gong et al., 26 Sep 2025). In current agent-security discourse, however, CSAgent most commonly denotes the latter system: a policy-based enforcement layer intended to constrain what computer-use agents may do, under which intents, and in which contexts.