PaperlayerView exact revision on arXiv

Source-linked AI summary

The Compiler May Read It, the Agent May Not: Keeping Part of a Research Code Away from a Coding Agent

Shobhan Roy

arXiv:2609.35557v2cs.CRcs.AIcs.SE

TL;DR

A physics-based solver needs protected model files to build, but a coding agent must not read those files. The paper classifies routes to the files and finds that the available enforcing mechanisms cannot identify which program is reading; a trusted broker can only approximate the rule.

  • Problem

    A solver must open protected model files to build, while an agent’s read can send their contents into a transcript that leaves the machine.

    Source: §I · p. 1

  • Method

    The article classifies fifteen routes to protected files against the container, permission rules, and sandbox, and examines a broker as an alternative.

    Source: §I · p. 1, §IV · p. 3

  • Results

    The enforcing mechanisms cannot name which program is reading, and the permission rules and sandbox leave five of fifteen routes uncovered by either.

    Source: §I · p. 1, §IV · p. 3

  • Takeaways & Limitations

    A separately trusted mediator outside the harness can only approximate the rule, with build-output filtering serving as the security control.

    Source: §III · p. 2

    The article does not offer an arrangement that holds against a hostile agent.

    Source: §VII · p. 5

Abstract

from arXiv · show

The compiler must read modules a physics-based solver cannot build without; the coding agent must not read that intellectual property. The harness, the software around the model that executes its tool calls, does not ship that rule. We classified fifteen read routes against a container, permission rules and a sandbox. None of the three can tell which program is reading.

I. Introduction

The article asks how a coding agent can edit and build a physics-based solver while protected model files remain unreadable to the agent, even though the compiler must open them. It examines whether the available mechanisms can distinguish which program is reading.

I. Introduction

  • The required rule is that the compiler may read protected files while the coding agent may not.The solver cannot build without those files, and agent reads can put their contents in a transcript that leaves the machine.Source: §I · p. 1
  • The enforcing mechanisms cannot state the rule’s criterion: which program is reading.The four mechanisms considered are the container, harness permission rules, harness sandbox, and a plain-language instruction file that does not enforce the rule.Source: §I · p. 1
  • The article classifies fifteen routes to protected files; permission rules and the sandbox cover different routes, leaving five covered by neither.It also tracks one deny list over five weeks and considers enforcement requirements and the costs of approximating the rule.Source: §I · p. 1

II. Terms and Trusted Components

The section defines the protected-read boundary and the ordinary-user position used to assess it. It also identifies trusted components and a build-recipe condition that can expose protected files.

II. Terms and Trusted Components

  • The compiler’s read and the agent’s read look the same to the mechanisms, although the compiler’s output stays on the machine and the agent’s read reaches its context and transcript.The compiler and agent run under one user account, with the compiler descended from the agent’s shell.Source: §II · p. 1
  • The harness runs the model and executes tool calls; its permission rules match command and path patterns, while its sandbox bounds shell commands.The harness refuses matching tool calls and places an operating-system boundary around shell commands.Source: §II · p. 1
  • “May not read” means protected bytes must not reach the model context or transcript, except through ordinary build output, including diagnostics and object code.Those outputs may carry content derived from protected files, so the rule is bounded disclosure rather than noninterference.Source: §II · pp. 1–2
  • The findings take an ordinary user’s position and do not assess resistance to a designated adversary.An ordinary user cannot change the harness, replace the runtime, or load a kernel security policy; a host-root administrator can install a kernel-level enforcer.Source: §II · p. 2
  • Build files must be trusted because an editable recipe or agent-supplied flags can print a protected file.The instruction file can state that the recipe and flags must be out of the agent’s reach, but it does not enforce that condition.Source: §II · p. 2

III. The Rule in the Security Literature

The section frames the desired rule as purpose-based access control but finds that the harness’s enforcing mechanisms cannot name the available stand-ins for purpose. It contrasts those controls with kernel enforcement and a trusted broker that only approximates the rule.

III. The Rule in the Security Literature

  • Purpose-based access control permits or refuses access according to its intended use, but the requester-authored command line gives the harness no independently controlled purpose declaration to check.Byun and Li describe asking the requester, registering an application purpose, or inferring purpose; their proposed check compares declared purpose against something the requester does not control.Source: §III · p. 2
  • The enforcing mechanisms cannot name the process that opened a file, its ancestry, or where its output goes—the available stand-ins for purpose.The finding concerns these stand-ins rather than purpose itself.Source: §III · p. 2
  • Type enforcement can explicitly authorize domains to access file types, but requires a privileged kernel policy loader unavailable to the ordinary user considered here.Boebert and Kain describe finite, explicit domain/type permissions; SELinux carries type enforcement in the kernel.Source: §III · p. 2
  • A trusted broker can isolate the protected files under a second user account and accept only a code revision request, then filter its reply.The recipe must be uneditable by the agent, and the reply must be limited to what the agent needs to act.Source: §III · p. 2
  • The broker only approximates the rule: filtering must control build-output disclosure, and returning failures can expose a line while pass/fail-only replies remove the edit-build-fix loop.It suits stable protected files separate from edited code, but under-development protected files lose the loop the agent was brought in for.Source: §III · p. 2

IV. The Blind Spot of Matching on Names

The section classifies fifteen routes by whether the deployment’s permission rules and sandbox refuse them, finding five routes covered by neither. Because the mechanisms match names rather than the consumer of a read, they leave gaps that a deny list alone cannot close.

IV. The Blind Spot of Matching on Names

  • Table I classifies fifteen prospective routes by whether each mechanism refuses them, using shipped rules, vendor documentation, reasoning, and uniform construction as evidence.The table gives a command for each route; its rows represent route classes, not attack frequency.Source: Table I · p. 3, §IV · p. 3
  • The coverage table is a classification for one deployment, not a measured rate of attack prevention; only a direct read and encoder invocation were tested against a decoy tree.The other thirteen routes were not run against protected files or the decoy.Source: §IV · p. 3
  • Two routes are covered by both mechanisms, seven by the sandbox alone, one by permission rules alone, and five by neither.Neither mechanism suffices on its own, and their union cannot be expressed as one policy through the harness interfaces.Source: §IV · p. 3, Figure 1 · p. 4
  • Five uncovered routes include an allowed build recipe, MCP policy server, hook, compiler preprocessing, and version-control history access.Each uses a program the agent causes to run with its authority through a name the rules already permit.Source: §IV · p. 4
  • The compiler can read a protected file to build, yet preprocessing the same file can print it; sandbox exemptions by command name cannot distinguish those output modes.The direct file read is refused while gfortran -E f is not.Source: §IV · p. 4
  • Across four revisions, the deny list grew from 14 to 586 rules, while the fourth revision added 30 rules and no new command name.That revision extended fifteen commands from directory protection to a single file; the rule language cannot require two targets to be protected alike.Source: §IV · p. 4

V. What Enforcement Would Require

The paper says enforcement must identify the program that consumes a file’s bytes at open time and control what that consumer can return. The harness mechanisms do not provide that enforcement point, while the required controls extend beyond file-open authorization.

V. What Enforcement Would Require

  • None of the harness mechanisms names the consumer of a read; research systems do so through process lineage or bounded access episodes, but require resources ordinary users lack.Those requirements include a runtime, kernel, or execution environment; this deployment has no enforcement point for the rule.Source: §V · p. 4
  • An enforcing check must run when a file opens and know which program will consume its bytes, rather than act only when a command launches.A command names a program; only the open names a file.Source: §V · p. 4
  • Process tags must survive child creation, and the consumer cannot be allowed to grant itself an exemption by starting the compiler.Otherwise a child can inherit its parent’s permission as a confused deputy, or the agent can exempt itself.Source: §V · p. 4
  • A compiler’s output needs a filter because diagnostics and compiled artifacts can carry protected-file content, including model constants.Stripping symbols and omitting debug information narrows the artifact channel but does not guarantee protection against reverse engineering; the paper offers no enforcement method for this filter.Source: §V · p. 4
  • Product documentation describes content-exclusion gaps: Copilot CLI and Agent mode do not support it, and Cursor says terminal and MCP tools cannot block access to ignored code.These are the stated limits for the products discussed.Source: §V · p. 5

VI. What the Arrangement Costs to Run

The denial record shows that command-level rules often refuse entire chained commands when only one part triggers a rule. Its counts describe command-surface denials, not protected-file access rates.

VI. What the Arrangement Costs to Run

  • 54 of 64 denial events involved a composite invocation, so commands surrounding the guarded token were refused with it.Each refused invocation counted once; a retried command counted again.Source: §VI · p. 5
  • 28 of 64 events were classified as confinement boundaries and 26 as destructive-verb gate denials.The remaining events comprised five boundary probes, four protected-target denials, and one event outside those headings.Source: §VI · p. 5
  • The protected-target count is a lower bound, and the corpus cannot establish denial rates or represent projects whose protected files are edited daily.The corpus captures command-surface denials, not refusals through built-in file tools; categories overlap, and no denial blocked ordinary work on protected files.Source: §VI · p. 5

VII. Related Systems and Scope of the Findings

Available mechanisms can express the access rule, but the examined options either require control beneath the agent or cannot distinguish the compiler’s read from the agent’s. The findings generalize beyond one vendor’s configuration, but do not claim protection against a hostile agent.

VII. Related Systems and Scope of the Findings

  • A process-tree enforcement system can encode the rule, but its inherited agent label blocks the compiler’s read unless the compiler is exempted, an exception the agent could invoke.Deploying the examined enforcement mechanisms requires control of a layer beneath the agent, such as the kernel policy loader, runtime, or harness.Source: §VII · p. 5
  • CaMeL governs where data may leave, while PORTICO binds repository paths to access modes and bounded justification episodes; neither was shown enforcing this read-level requirement.PORTICO models a single consumer, unlike a case where a compiler also opens the protected bytes.Source: §VII · p. 5
  • The general finding is that command matching does not mediate file opens, path rules cannot identify the reader, and inherited permissions cannot distinguish a build from its caller.Exact tool scopes, rule syntax, and documented exclusions are vendor-specific and may change with releases.Source: §VII · p. 5
  • The deployed arrangement remains useful but leaves the compiler route open, so build output, diagnostics, and compiled artifacts may expose protected content.The assessment concerns mechanisms available to an ordinary user and does not offer an arrangement that holds against a hostile agent.Source: §VII · p. 5

Availability and Prior Publication

The authors release the configuration and analysis scripts, while withholding the denial corpus because it contains real project paths and a remote host. They distinguish this article’s results from their earlier practitioner articles.

Availability and Prior Publication

  • The configuration is public under an MIT license, and scripts for the table, revision history, and denial counts are released with the article.The classification script runs against the released configuration.Source: Availability and Prior Publication · p. 6
  • The denial corpus is not released because it records real project paths and a real remote host; only counts and redacted command shapes are reported.Source: Availability and Prior Publication · p. 6
  • The earlier practitioner articles describe the deployment, but the requirement, coverage table, revision history, denial corpus, and composition claim appear here for the first time.The sequel supplied three source-(A) routes for Table I; neither earlier article contains the results reported here.Source: Availability and Prior Publication · p. 6
Loading 2609.35557v2…