Names Are Not Objects: Object-Bound Isolation for Compromised Coding Agents

This paper attempts to solve the problem of compromised AI coding agents performing unauthorized operations on the host machine and escaping sandboxes.

• Scenario and importance: Coding agents read untrusted repositories, issues, and documents on developer machines and invoke local tools with user privileges. The authors point out that prompt injection defenses cannot fully prevent models from being maliciously induced, and the system perimeter must have classic confinement capabilities under the premise that the agent is already compromised.
• Shortcomings of existing mechanisms: Existing command whitelists, permission confirmation dialogs, and command sandboxes cannot effectively constrain. The authors analyze vulnerabilities publicly disclosed from 2025 to 2026 and note that whitelists allow commands with code execution or file writing options; dialogs only show symbolic link names; malicious configurations or virtual environments planted in the workspace are loaded and executed by host tools outside the sandbox after the session ends.
• Core observation: The authors point out that the root cause of successful attacks is the disconnect between name checks and the objects that take effect (Name/Object Gap). Defense mechanisms check path strings, command arguments, or directory names, while the underlying kernel or subsequent parsing tools actually act on symbolic link targets, implicitly resolved bare repositories, or interpreters loaded by editors, constituting check-to-use (TOCTOU) vulnerabilities in the agent toolchain.
• Solution: The paper proposes the Zero-Trust Agent Cells (ZTAC) architecture, following the principle of "authorize the specific objects that will be used, and only use authorized objects," with an independent Broker resolving and binding objects, and compiling the unified policy into the sandboxes of derived programs.
• Threat model:
  • Attacker goals: Read sensitive files outside the workspace, in other cells, or unauthorized; corrupt external files, repository metadata, or unauthorized sensitive files; execute code outside the policy (such as Shell, repository configuration commands, or files subsequently executed by host tools); exfiltrate data to unauthorized endpoints; impersonate other cells, replay requests, or abuse approvals.
  • Attacker knowledge: Knows the system security policy and all cell public keys.
  • Attacker capabilities: Fully controls the model, agent runtime, and any code written and run inside the cell; can plant arbitrary files such as symbolic links, hard links, and .git directories in the workspace before session startup (repository poisoning).
  • Victim system and trust assumptions: The victim system is the developer's local machine; the system trusts the kernel and its sandbox, the Broker and its configuration, policy makers, and human reviewers for approvals; programs derived by the Broker are untrusted.

The paper organizes related work into five directions, positioning itself at the concrete underlying object execution boundary beneath tool invocation policies.

• Restriction and reference monitors:
  • Janus (1996) enforced restrictions via system call interception but faced TOCTOU vulnerabilities when the kernel re-read names; Ostia (2004) instead delegated sensitive system calls to a trusted agent, a pattern ZTAC's Broker follows.
  • Capsicum (2010) explored eliminating ambient authority through capabilities; STING (2012) analyzed defenses against pathname resolution attacks, including trusted directory traversal, disabling symlink following, and identity verification.
• System-level agent defenses:
  • CaMeL (2025) separates planning from untrusted data and checks capabilities before tool calls; FIDES (2025) tracks information flow labels; Progent (2025), AgentSpec (2026), and Conseca (2025) constrain tool calls through policies.
  • IsolateGPT (2025) isolates applications; ACE (2026) separates planning and execution; SEAgent (2026) introduces mandatory access control; AC4A (2026) manages resource permissions; AuthGraph (2026) implements provenance-based authorization; GAAP (2026) enforces information flow control; Agent libOS (2026) controls typed capabilities; PORTICO (2026) revokes capabilities when subgoals complete.
• Approval and file systems:
  • Approval Laundering (2026) binds call fields to prevent delegation mismatches; the authors designed a control variant of it, testing mismatches when parameters are fixed but symlink targets or staging state change.
  • YoloFS (2026) stages changes for review, inspection, and rollback; Rashidi (2026) reports isolation fragmentation and TOCTOU issues.
• Agent sandboxes in practice:
  • Commercial systems such as Claude Code (2025) and Codex (2026) combine command sandboxes with prompts; Sandlock (2026) restricts code on Linux via Landlock and seccomp and moves runtime-state-dependent decisions to a supervisor, but trusts the agent runtime itself.
  • Public escape cases show workspace files can be executed outside the command sandbox; ZTAC treats the agent runtime itself as compromised and applies kernel-level sandbox restrictions.
• Baseline methods and benchmarks:
  • Baseline setup: B0 (direct tool access), B1 (command and path whitelist), B2 (B1 plus a command execution sandbox similar to deployed systems), Zbroker (ZTAC Broker without cell sandbox), and 14 ablation variants.
  • Evaluation suite: the authors' suite of 74 attacks (including 10 reproductions of public vulnerabilities), 46 single-operation benign workloads, 7 end-to-end development workflows, and 52 path access consistency cases.
• Positioning: the authors note that existing agent security work mainly focuses on high-level tool invocation policy languages, whereas ZTAC provides a concrete execution boundary beneath policies, through resolution, descriptor-based file access, uniformly compiled sandboxes for derived programs, and approval bound to underlying concrete object state.

ZTAC follows the single rule "authorize the concrete objects that will be used, and use only authorized objects," building its defense through cell kernel isolation, a centralized trusted Broker, unified compilation at dual execution points, and object-bound approval.

Overall architecture and cell isolation

• Single-session independent cell: each agent deploys one trusted Broker and one untrusted cell. The cell is a process tree launched by the launcher under a deny-by-default Seatbelt kernel sandbox profile.
• Strict least privilege: the cell is only allowed to read system libraries and frameworks needed to load the runtime, read its own private key, execute its own binaries, and communicate with the Broker over a single Unix socket.
• No direct access: the cell is forbidden from directly reading workspace files, opening network sockets, signaling other processes, or creating other processes. All file reads/writes and network calls are converted into requests sent to the Broker.
• Request authentication: each request carries JSON parameters, free-text intent, a timestamp, a 128-bit nonce, and an Ed25519 signature. The Broker verifies the signature before processing and appends it to a replay log synchronously; the intent is only shown to reviewers and is not used for authorization.

Resolve-before-deciding and race-free execution

• Resolve before deciding: the Broker converts input parameters into concrete objects before evaluating policy. Paths are normalized via realpath (restoring true case on macOS), checked to be inside the workspace; if the target is a regular file with a hard link count greater than 1, approval is always required because unknown aliases exist; device and inode are also recorded.
• Descriptor-based race-free access: to prevent directory-swap races between check and use, adapters do not open path strings directly; instead they open the workspace root and traverse relative paths step by step using openat(O_NOFOLLOW), comparing the final inode with the one resolved at decision time, aborting on mismatch.
• Safe atomic writes: when writing a file, a temporary file is created in the target directory and renameat atomically overwrites the target path, thereby replacing a symlink at the target rather than following it.
• Provenance: the Broker records SHA-256 hashes of content written by each cell. A cell may re-read sensitive files it wrote itself and that have not been tampered with, without approval.

Policy definition and unified compilation at dual execution points

• Path policy: 26 rules by default, applied by first match. Reading or writing potential credentials (e.g., .env, .pem) and handoff files (e.g., shell scripts, CI configs, .vscode/, **/HEAD, **/pyvenv.cfg) requires approval; writes to .git/ are directly denied.
• Unified sandbox for derived programs: the Broker compiles the same path rules in reverse into a Seatbelt profile, applied to all derived subprograms (e.g., git, python3).
• Stricter sandbox design: the derived-program sandbox forbids networking, forbids connecting to the Broker socket, and forbids creating new processes (preventing background daemons); read-restricted rules also forbid writes in the sandbox (preventing alias creation via link/rename); operations requiring human approval are directly denied in the sandbox; if the workspace contains files with multiple hard links, program startup is denied.
• Hardened Git: GIT_DIR and GIT_WORK_TREE are pinned to the workspace, global config is forbidden; 14 settings are locked via command line (disabling hooks, fsmonitor, pager, external diff, etc.); subcommands are required as the first argument to block global options like -c.

Object-bound approval and tamper-evident audit

• Object-bound approval: when policy requires approval, the pending record shows the reviewer the resolved concrete operation (e.g., reading config.txt is displayed as reading .env). Approval is strictly bound to the cell, tool, normalized parameters, and the resolved concrete objects (for Git, including HEAD, current branch, packed refs, and index hashes).
• Single-use and expiry: approvals expire after 10 minutes and are marked destroyed immediately after first use; when an approval is used, object resolution binding is recomputed, and execution is denied if the file was replaced, a symlink was redirected, or the staging area changed.
• Signed hash-chain audit: each legitimate request records authorization before execution and result status after execution. Records include the predecessor hash and are signed by the Broker; a receipt is returned to the cell to guarantee tamper-evidence and integrity.

The paper conducts experiments around containment capability (RQ1), contributions of each mechanism (RQ2), benign usability (RQ3), and system overhead (RQ4).

Experimental Setup

• Test environment: Runs on a Mac18,5 machine with an Apple M6 chip and 24 GiB memory, operating system macOS 27.0.1, tool versions git 2.54.0 and Python 3.9.6.
• System configurations under test: B0 (direct tool access), B1 (tool whitelist), B2 (B1 with a regular command sandbox), Zbroker (ZTAC Broker without cell sandbox), and full ZTAC.
• Test suite and sample sizes: The attack suite contains 74 attacks (15 file system, 21 program execution, 8 handoff, 9 network, 5 protocol, 6 approval, 10 direct bypass); benign workloads contain 46 single operations and 7 end-to-end workflows; 52 path consistency cases; 10 race tests.
• Model and driving method: The experiments did not run an LLM; attacks and benign requests were generated by the evaluation framework through scripts, which the authors say decouples the enforcement mechanism from prompt injection uncertainty.
• Metrics and oracle determination: Ground-truth oracles are used to check canary leakage, external file modification, repository history commits, or marker file creation; metrics are classified as Succeeded, Escalated, and Blocked.

Main Results

The paper's test results on each category of the 74-attack suite are shown in the table below (per Table 2):

Swipe horizontally to read the table

Attack category	Number of cases n	B1 succeeded	B2 succeeded	Zbroker succeeded/escalated	ZTAC succeeded/escalated
File system	15	11	7	0 / 5	0 / 5
Program execution	21	18	12	0 / 2	0 / 2
Handoff	8	8	8	0 / 5	0 / 5
Network	9	8	8	2 / 1	2 / 1
Protocol	5	5	5	0 / 0	0 / 0
Approval	6	6	6	0 / 0	0 / 0
Direct	10	10	10	10 / 0	0 / 1

• Baseline defense performance: Per Table 2, unprotected B0 failed on all 74 attacks; B1 blocked only 8 and failed 66; B2 blocked 18 and failed 56, failing on all handoff, protocol, approval, and direct attacks.
• Necessity of cell sandbox: Zbroker without a cell sandbox failed on all 10 direct attacks (such as directly reading SSH keys, tampering with approval storage), and the authors state the reference monitor cannot be bypassed.
• ZTAC containment performance: Full ZTAC successfully blocked 58 attacks and escalated 14 to review, with only 2 network exfiltration attacks succeeding; both used authorized endpoints to exfiltrate credentials via Base64 encoding or chunked sending, and the authors state pattern matching cannot intercept such exfiltration.

Publicly Disclosed Vulnerability Reproduction Evaluation

• Evaluation targets: Reproduced 10 agent security vulnerability mechanisms publicly disclosed from 2025 to 2026 (per Table 3), covering Claude Code, Codex CLI, Copilot CLI, Cursor, and Antigravity.
• Comparison results: B1 missed all 10; B2 blocked 4 vulnerabilities requiring operations outside the workspace in derived programs but missed 6 involving workspace file or symbolic link writes; ZTAC blocked 7 and escalated 3 to review (editor tasks, agent hooks, and nested HEAD file writes), with none successfully escaping.

Mechanism Contributions and Ablation Experiments

• Ablation result analysis (per Table 4): The approval layer contributes the most; removing it leads to 18 successful attacks; removing resolution classification leads to 5 successful attacks (symbolic link and hard link aliases); removing derived program sandbox rules leads to 7 successful attacks; removing strict outbound policy leads to 3 successful attacks.
• Object binding and race defense: Removing object binding makes approval redirection and stale staging state attacks succeed; directory swap race experiments (per Table 7) show that when both descriptor traversal and fork prohibition are removed, races succeed in all 10 tests (10/10), while keeping either mechanism yields 0/10 successes.

Benign Utility and Workflow Performance

• Single operations and workflows (per Table 5 and Table 8): Of 46 single operations, ZTAC completed 43, required 8 approvals, and failed 3 (all due to prohibited process creation or protected virtual environments); of 7 end-to-end workflows, it completed 4 and failed 3 (virtual-environment, subprocess-build, tracked-edit-commit-all).
• Failure mechanisms: Workflow failures were due to prohibition of subprocess creation, protection of virtual environment metadata, and deliberate lack of support for commit -a with workspace scanning.

Runtime Overhead Evaluation

• Latency tests (per Table 6): Median latency for no-op requests (ping) was 4.0 ms (p99 4.6 ms), with authentication and replay log synchronous flushing taking 3590 µs; 4 KiB read was 4.0 ms, 4 KiB write was 7.1 ms; echo added 8.5 ms, git status added 9.5 ms, python3 added 18.4 ms (reaching 26.4 ms).
• Throughput and verification: A single client completed about 200 4 KiB reads per second, and multiple clients (up to 16) reached about 300 per second; audit log verification speed was about 44,000 records per second.

Other Ablations and Analyses

• Removing signature authentication makes 3 attacks succeed: identity forgery, unregistered clients, and message tampering (Table 4).
• Removing timestamp and nonce freshness makes 2 attacks succeed: request replay and replay after restart (Table 4).
• Removing full outbound request scanning makes 2 attacks succeed where keys are carried in URLs or request headers (Table 4).
• Removing version control protection makes 1 attack succeed that overwrites configuration via git show (Table 4).
• Removing the combination of version control protection and execution sandbox makes 5 Git-related attacks succeed (Table 4).

The paper discusses architectural limitations and future directions in Section 7, and clarifies evaluation coverage in the experimental design.

Limitations and future directions noted by the authors

• Confidential data exfiltration through allowed channels (from Section 7): ZTAC only controls data flow, not encoded content. If a cell has both sensitive read permission and outbound network permission, data can be exfiltrated via arbitrary encoding (e.g., Base64), which regex scanning cannot prevent; the authors note that a thorough solution requires dynamic information flow tracking or policies that isolate data from egress.
• Handoff rules rely on enumeration of known tool features (from Section 7): rules preventing subsequent execution by external tools only cover known tools (e.g., editor tasks, Git HEAD, virtual environments); tools not covered by the rules cannot be defended against; meanwhile, ordinary build files such as Makefiles or test scripts cannot be blocked by rules alone and must rely on human review.
• Concurrent workspace modification and the object binding premise (from Section 7): write operations use fstatat and renameat, relying on a single lock for serialization and a prohibition on concurrent child processes to guarantee atomicity; if external processes concurrently modify the workspace (e.g., a developer's local editor), this guarantee fails; programs and working directories are currently bound by path rather than descriptor.
• Git approval state coverage (from Section 7): Git state binding currently hashes only HEAD, the current branch, packed refs, and the index, not other loose branch references or the full workspace state; approval for merge, reset, checkout, or rebase cannot yet guarantee consistency of the reviewed version.
• Human reviewer deception and fatigue (from Section 7): the system escalates high-risk operations to human approval, but cannot judge whether the code itself is harmful; reviewers may be persuaded by intent descriptions or fatigued by frequent pop-ups; the paper does not test reviewer accuracy or fatigue.
• Coarse sandbox restrictions and platform portability (from Sections 7 and 5): the sandbox allows global reads of file metadata to determine the existence of external paths; coarsely prohibiting process creation causes legitimate build tools to fail; in the Linux port, Landlock cannot directly express negative rules that exclude files within a directory.

Evaluation coverage

• Tested system environment: experiments ran on a single machine with an Apple M6 chip and macOS 27.0.1; the tested unit comprised two cells (attacker cell A and victim cell B).
• Workload scale: the evaluation is based on 1 small Python project, including 74 attack cases, 46 single-operation workloads, and 7 end-to-end workflows.
• Model and agent integration: both attack and operation tests are driven by scripted requests; the paper does not test off-the-shelf commercial agent runtimes.
• Sandbox comparison implementation: baseline B2 uses a simulated Seatbelt profile to approximate a deployed sandbox, without directly running the commercial product's own sandbox environment.
• Network and concurrency handling: network endpoints are matched only by hostname; the paper does not report defenses against DNS rebinding; Broker request handling is serialized with a single lock.

This paper proposes ZTAC, an object-binding-based zero-trust confinement architecture for compromised AI coding agents.

• Problem positioning: Coding agents face prompt injection risks. The core reason existing command whitelists, permission dialogs, and command sandboxes frequently fail is that defense mechanisms check the "names" input by users or models, while the system's underlying layers and subsequent host tools execute specific "objects," creating cross-layer name resolution disconnects and check-to-use (TOCTOU) vulnerabilities.
• Method architecture: ZTAC follows the principle of "authorize the specific objects that will be used, and only use authorized objects." It runs agents in strictly restricted kernel sandbox cells, with all tool operations mediated by a trusted Broker; before decisions, the Broker resolves requests into concrete objects, eliminates path races through openat descriptor traversal, and compiles the same security policy into Seatbelt sandboxes of derived programs; approval operations are strictly bound to resolved objects and repository state and are single-use only.
• Security validation: In 74 attack tests, unprotected B0 missed all attacks, regular whitelist B1 missed 66, and B2 with command sandbox missed 56; ZTAC blocked 58 and escalated 14 to review, missing only 2 encoding-based leakage attacks through allowed channels; it also contained all 10 reproductions of publicly disclosed vulnerabilities (blocking 7 and escalating 3).
• Utility and overhead: In 46 single-operation benign workloads, ZTAC completed 43 and generated 8 review prompts; in 7 development workflows, it successfully executed 4; median latency for no-op requests was 4.0 ms, and running Python added 18.4 ms median latency.
• Author conclusions: The authors believe compromised coding agents should be treated as local malicious attackers and must be stripped of environment privileges; by strictly binding authorization to underlying objects and enforcing a unified policy across all derived programs, the harm boundary of compromised agents can be contained at the cost of measurable performance and some multi-process workflows.