Papers
Topics
Authors
Recent
Search
2000 character limit reached

Permission Denied: Policy-Graded Evaluation of Coding Agents in Hardened Environments

Published 2 Aug 2026 in cs.CR and cs.AI | (2608.02670v1)

Abstract: Coding agents increasingly run inside organizations whose security controls (scoped credentials, restricted egress, read-only filesystems, non-root execution) constrain them like any other software. Existing benchmarks, however, evaluate agents almost exclusively in permissive sandboxes, so it is unknown how performance changes when policy is enforced. In this work, we evaluate 12 coding agents on Terminal-Bench 2.1 across nested security policy levels derived from common real-world enterprise restrictions. Hardening is never free but far from uniform: under the strictest policy, success losses reach 18.3 points and cost inflation 167.3\%, and the two axes disagree; the model that best preserves success is also the one that loses the most efficiency, so model choice is policy-dependent. Beyond aggregate scores, we characterize how agents behave when policy blocks their actions and decompose the failures hardening induces: runs grind into timeouts or wrong solutions rather than stopping early, in a mix that differs by model. To ground comparisons, we verify task solvability under the strictest policy, separating model failures from tasks the policy forecloses. We release Boundary-Bench, an open-source hardening plugin enabling policy-constrained evaluation of coding agents on Terminal-Bench and compatible benchmarks.

Summary

  • The paper introduces Boundary-Bench, a framework that layers graded security policies (network, filesystem, privileges) onto coding agent benchmarks.
  • It finds that policy hardening causes non-uniform degradation, with some models facing significant success loss and drastic cost inflation.
  • The study underscores the need for policy-adaptive agents and cost-aware scoring to ensure reliable deployment in secure, enterprise environments.

Policy-Enforced Security as a First-Class Axis in Coding Agent Evaluation

Motivation and Context

With the increasing real-world deployment of coding agents in enterprise environments, these agents encounter operational security controls—such as scoped credentials, restricted egress, read-only filesystems, and enforced least privilege—that are standard in modern IT infrastructure. However, most contemporary benchmarks, like Terminal-Bench and FeatureBench, historically assess agent performance in permissive, unconstrained environments, ignoring the operational impacts of security policy enforcement. This gap leaves unknown how agent success and associated efficiency are affected by practical organizational constraints.

The paper "Permission Denied: Policy-Graded Evaluation of Coding Agents in Hardened Environments" (2608.02670) systematically addresses this shortcoming via policy-graded benchmarking of coding agents. The authors introduce Boundary-Bench, a framework for layering natively enforced execution policies onto standard agent benchmarks, enabling rigorous, reproducible measurement of how performance and resource cost shift across incremental policy hardening corresponding to well-established control baselines (e.g., NIST SP 800-53).

Boundary-Bench and Policy Enforcement Framework

Boundary-Bench provides an extensible evaluation harness, enforcing security policies directly at the system level—without agent cooperation—using three orthogonal control axes: network egress, filesystem writability/scope, and process privilege. Each axis features a three-level granularity: open (unrestricted), restricted, and locked (maximally constrained). The composition of these axes yields a cumulative "severity ladder":

  • Control: No restrictions; agents run as root, with open network and full writable filesystem.
  • Non-root: Only privilege dropped; agent executes as non-root, but retains open network and writable filesystems.
  • NIST-derived high: Simultaneous enforcement of a strict egress allowlist (developer domains), read-only global filesystem (except a dedicated writable workspace), and non-root execution with all privilege escalation blocked (no sudo, capabilities removed, setuid bits stripped).

The intention is to model the real-world trajectory as policy hardening increases, tracking the drift in agent performance, efficiency, and behavior as a function of enforced policy, not simply as a one-off state.

Empirical Evaluation on Terminal-Bench 2.1

Experimental Design

Twelve model–harness bundles were evaluated, spanning major model families (OpenAI GPT-5.6 Sol/Terra/Luna, Anthropic Claude Sonnet/Opus/Fable, xAI Grok, and open weights via Terminus-2). Each bundle was assessed over 89 coding tasks from Terminal-Bench 2.1 under every policy configuration, with three valid replicate trials per task/policy pair. The environment for each run was a clean cloud sandbox, fully enforcing the specified policy with no agent-side knowledge or adaptation.

Benchmarked Metrics

Primary outcomes were per-bundle success rate (fraction of tasks solved) and mean cost (USD spent on model inference/tokens per-trial), constituting a two-dimensional success–cost Pareto frontier. Task solvability under the strictest policy ("solvability witness") was established by replaying shipped reference solutions and constructing minimal policy-compliant alternatives when necessary. Figure 1

Figure 1: Hardening moves the Pareto frontier down and to the right, by amounts that differ across model-harness bundles.

Core Findings: Non-Uniform Degradation and Currency of Cost

Pareto Frontier Deformation under Hardening

Every evaluated bundle is forced down and to the right (decreased success, increased cost) as policy severity intensifies, but not in a uniform or predictable fashion. The magnitude and "currency" of degradation—whether an agent loses more success or suffers more from inflated cost—are model/harness-specific, implying that model selection must be policy-aware.

  • (Figure 1) shows that, under NIST-derived high, the success–cost Pareto frontier is significantly shifted, with certain agent bundles accruing drastically more inefficiency for relatively preserved success, and others losing success in favor of retaining more efficiency. Figure 2

    Figure 2: Every bundle loses success and gains cost non-uniformly under strict policy; some models incur high cost inflation for minimal success loss.

Quantitatively:

  • Grok 4.5 has the smallest loss in success rate (7.1{−7.1}pp) but with extreme cost inflation (+167.3%+167.3\% over baseline).
  • Claude Sonnet 5 loses the most success (18.3{−18.3}pp) with only moderate cost increase (+21.4%+21.4\%).
  • GPT-5.6 Luna accepts a large drop in success (18.0{−18.0}pp) for the lowest additional cost (+16.0%+16.0\%).

Failure Mode Decomposition

Policy-induced performance degradation does not trigger simple early surrender. Instead, it leads to protracted trajectories; failures transition predominantly into timeouts (e.g., agent runs until the wall-clock limit without solution) and wrong solutions (completed trajectories that fail verification), with little increase in early quits.

Mechanism of Cost Inflation

Policy hardening causes the median cost to increase nearly threefold (Figure 3), regardless of whether success is preserved or lost. The main source of added cost is repeated workarounds—agents detect a blocked or denied operation (e.g., network blocks or denied privilege), retry alternate approaches, or reconstruct toolchains from allowable sources, expending budget often with no gain in outcome. Figure 3

Figure 3: Enforcing security policy (NIST-derived high) triggers a near tripling of per-run median cost, affecting both successful and unsuccessful runs.

  • Notably, both passing and failing runs incur this inflation—failed trajectories typically consume the full inflated budget, not less.

Task-Level and Solution Compatibility Analysis

To separate true agent failures from those that stem from task–policy incompatibility, the authors establish a "solvability witness" for each task: either the original reference trajectory or a minimally adapted, policy-compliant one. Out of 89 tasks, 82 remain solvable under strict policy; the remaining 7 are design-blocked (e.g., task requirements inherently demand forbidden resources or actions). This clarity enables blame assignment: failure on a solvable task indicates agent–enforcement interaction, while failure on inherently blocked tasks reflects inevitable incompatibility.

Policy-induced cost and success penalties are concentrated almost exclusively on the subset of tasks whose canonical reference solution fails under policy (Figure 4), while unaffected tasks preserve baseline efficiency and success. Figure 4

Figure 4: Cost inflation under policy is concentrated on tasks whose reference solution is incompatible with the enforced policy; unaffected tasks remain near parity.

  • On affected tasks, mean cost multipliers rise to 2.59×2.59\times baseline (NIST-derived high), while unaffected tasks remain close to 1.14×1.14\times.
  • The same stratification reliably predicts success penalty.

Blocked Action and Exposure Statistics

A granular analysis of blocked operations reveals that policy enforcement has concentrated impact:

  • Under strict policy, about a third of all trials encounter at least one blocked action, primarily egress denials.
  • A small number of tasks ("head tasks") account for a majority of blocked actions, while most tasks are only minimally impacted.
  • For tasks that are solvable, encountering a blocked action is associated with lower pass rates and increased cost, but many passing runs incur at least incidental denials as part of alternate solution strategies.

Limitations

  • Results are obtained on Terminal-Bench 2.1 exclusively; generalization to other benchmarks would require analogous solvability audits and enforcement integrations.
  • Attribution is at the model–harness bundle level due to architectural dependencies.
  • Only one operating point (high effort, three trials per cell) was evaluated; results may vary at different trial depths or agent effort configurations.
  • Policy implementations are modeled on standard controls but do not constitute a deployment-ready security baseline.

Implications and Future Directions

Practical Implications

Benchmarks must report agent performance under realistic policy constraints to inform meaningful model selection for enterprise deployment; unconstrained leaderboards are fundamentally misleading when security controls are non-negotiable in operational contexts.

  • Cost-aware scoring (Pareto analysis) reveals discriminative headroom masked by unconstrained benchmarks, demonstrating that high aggregate performance can mask deeply divergent failure and cost profiles under realistic constraints.
  • Reference solution compatibility is a powerful predictor of which tasks (and thus agent trajectories) will be impacted by security controls; this analysis can be performed prior to agent benchmarking.

Theoretical Implications

Non-uniform, model-dependent responses to policy enforcement suggest that reasoning, retry, and error-recovery strategies in current coding agents are highly brittle, lacking explicit adaptivity to environmental restrictions. Policy-compliant solution synthesis is neither algorithmically trivial nor emergent.

  • There is a clear need for policy-adaptive agents: architectures that proactively model, detect, and dynamically work around (or even anticipate) execution-time denials, rather than reacting naively.

Speculation on Future AI Directions

We anticipate a new generation of evaluation standards that integrate security policy axes alongside task complexity and stochastic perturbations. The development of agents that are robust not only to adversarial input (see e.g., (Zhu et al., 2023, Wang et al., 2021)) or environmental fault injection (Kara et al., 28 Sep 2025, Gupta, 3 Jan 2026) but to systemic privilege and access constraints, will be essential for production deployment across organizational boundaries.

  • Policy-sensitive meta-planning, runtime privilege detection, and pro-active capability negotiation are likely to become core features in agent system design.
  • Benchmark construction methodologies will need to expand solvability audits and artifact-corrected scoring, as over-specified verifiers and reference solution dependencies can otherwise confound interpretation of baseline performance.

Conclusion

This paper establishes, via robust empirical evidence, that coding agent performance under realistic security policies is substantially and non-uniformly degraded, with strong dependence on both agent architecture and specific task-policy interactions. Reporting agent performance without a policy dimension obscures critical deployment risks and misguides model selection. Embedding graded, natively enforced security controls into agent benchmarks, accompanied by task solvability audits and cost-success Pareto analyses, should be normalized in agent evaluation practice. This enables accurate operational forecasting and accelerates the development of agents capable of effective, compliant performance in real organizational contexts.

Natural future work includes the extension of this methodology to additional benchmarks and environments, and the engineering of agents that actively adapt not only to input and tool perturbations, but to security posture itself—from inference to planning to execution.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

Explain it Like I'm 14

Overview

This paper studies how AI coding agents (think: super-smart coding assistants that can use a computer) behave when they have to work on “locked‑down” computers like those in real companies. In real life, companies limit what software can do: no admin (root) access, limited internet, and many folders set to read‑only. Most AI agent tests don’t include these limits, so their scores can look better than what you’d get in the real world. The authors fix this by adding security rules to a popular benchmark and measuring how much performance and cost change.

What questions did the paper ask?

  • How much do coding agents’ success rates drop, and how much more do they cost to run, when real security rules are turned on?
  • Do different agents fail in the same way, or do they struggle differently?
  • Which tasks become truly impossible under strict rules, and which are still solvable?
  • Can we fairly compare agents across different “lockdown” levels?

How did they test it?

The team built a tool called Boundary‑Bench that adds real, operating‑system security controls on top of an existing test suite called Terminal‑Bench.

Here’s the setup in everyday terms:

  • Three “lockdown levels” (like school computer restrictions):
    • Control: everything open (admin access, full internet, can write to files anywhere).
    • Non‑root: you’re no longer an admin, but internet and files are still open.
    • NIST‑derived high: strict mode with:
    • Limited internet (only certain sites allowed),
    • Read‑only system folders (you only get a small workspace you can write to),
    • No admin powers at all.
  • The rules are enforced by the computer itself (Linux), not by asking the agent to behave. So if an agent tries something it’s not allowed to do, the system just says “permission denied.”
  • They tested 12 different “model + agent harness” bundles on 89 tasks. Each task was tried three times per bundle per policy level.
  • They measured:
    • Success rate (how often tasks were solved),
    • Cost (money spent on model tokens),
    • How runs failed (timed out, wrong answer, or quit early),
    • Which actions were blocked (internet, files, or admin).
  • They also checked which tasks are still solvable under the strictest rules. If the original official solution no longer worked, they tried to write a new, policy‑friendly solution. They also fixed a few unfair test checks that were too picky (for example, insisting a tool be installed in an exact folder that became read‑only).

What did they find?

  • Hardening always hurts, but not equally:
    • Under the strictest policy, success rates dropped by as much as 18.3 percentage points.
    • Costs went up—sometimes a lot—by as much as 167.3%.
    • Importantly, agents didn’t all react the same way. Some lost more success but kept costs lower. Others kept success higher but spent much more. In other words, you “pay” either in wins or in money, depending on the agent.
  • The “best trade‑off line” (the set of agents that give you the most success for the least cost) shifts downward and to the right as rules get stricter—meaning worse success and higher cost overall—but which agents sit on that line changes with the policy level. So the “best” agent depends on how locked down your environment is.
  • How they fail changes:
    • Under strict rules, failures mostly turn into:
    • Timeouts (they run the whole time but don’t finish), and
    • Wrong solutions that complete but don’t pass checks.
    • Agents rarely just give up early. They grind longer, trying workarounds.
    • Even successful runs take longer: more time, more tool calls, and more tokens.
  • Cost balloons even when success doesn’t drop:
    • In deep tests of two tasks, the median cost per run almost tripled under strict policy.
    • Why? Agents try workarounds: rebuilding tools from source, swapping data sources, or otherwise doing extra steps because the usual path is blocked.
  • Which tasks are actually possible?
    • 82 out of 89 tasks are still solvable under strict policy.
    • 7 tasks are “blocked by design” (the policy forbids something the task truly needs).
    • The biggest success and cost penalties cluster on tasks where the “canonical” (official) solution breaks under policy. If the official solution still works under policy, agents usually do fine.
  • What gets blocked most?
    • Internet access is the most common (and repetitive) blocker. When an agent hits a blocked URL, it often keeps trying, piling up many denied attempts.
    • Blocked actions are far more frequent on tasks whose normal solution path conflicts with the policy.

Why is this important?

  • Realism: Companies run agents under strict rules. Scores earned in anything‑goes test labs can be misleading. This work shows how to test agents with those real limits in place.
  • Better choices: Because different agents “pay” in different ways (success vs. cost), the best agent for you depends on your company’s policy. A single leaderboard without policy doesn’t tell the whole story.
  • Budgeting: Expect longer runs and higher token bills under stricter policies, even when tasks still succeed. Plan capacity and costs accordingly.
  • Fair benchmarking: Benchmarks should include a “policy axis” (different lockdown levels) so results match real deployments.
  • Practical tool: Boundary‑Bench is open‑source, so others can evaluate agents under enforced policies too.

Key takeaways

  • Locking down the environment always makes agents perform worse and/or cost more, but how much—and in which “currency”—depends on the agent.
  • Under strict policy, agents don’t quit; they spend more time and tokens trying workarounds, leading to more timeouts and wrong answers.
  • Most tasks remain solvable, but a few are truly impossible under tight rules—and benchmarks should say so.
  • Knowing whether the official solution path still works under policy is a strong hint about where you’ll pay in success and cost.
  • Agent selection should match your organization’s security policy, and benchmarks should report results under those policies.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a concise, actionable list of what remains missing, uncertain, or unexplored in the paper. Each item highlights a concrete direction future researchers can pursue.

  • Attribution to specific policy axes
    • Isolate the marginal and interaction effects of network egress, filesystem scope, and privilege restrictions via a full factorial design (e.g., N×F×P with intermediate levels and gradients of allow-lists/RO scope).
    • Quantify sensitivity to allow-list composition (domains, mirrors, rate limiting, DNS-only egress) and to filesystem lockdown variants (RO HOME, sandboxed temp, seccomp profiles).
  • External validity across settings
    • Replicate on additional benchmarks and modalities (e.g., SWE-bench, OSWorld, web agents), non-Linux OSes (Windows, macOS), GUI/IDE agents, and alternative enforcement mechanisms (SELinux/AppArmor, eBPF, VMs vs containers).
    • Assess generalization to GPU-accelerated tasks, distributed builds, and multi-service workflows.
  • Harness vs model disentanglement
    • Systematically ablate model–harness pairings across the full roster, vary “effort” modes, and instrument harness retries/tools to identify which agent design choices drive timeouts vs wrong solutions.
  • Statistical power and uncertainty
    • Increase trials per cell, report confidence intervals across all key figures (not only selected ones), and test for heavy-tailed cost distributions and run-to-run variance under policy.
  • Safety-layer confounding
    • Measure the impact of provider safety gates with safety-disabled or private endpoints, compare direct vendor routes vs aggregators, and model whether enforcement severity modulates refusal incidence.
  • Policy realism and enterprise mitigations
    • Evaluate configurations with typical enterprise mitigations (internal artifact mirrors/proxies, pinned toolchains, hermetic builds) to estimate the “policy tax” under realistic dev infra.
    • Calibrate the enforcement stack against additional NIST SP 800-53 controls and document coverage gaps (effectiveness, not just cost).
  • Policy-aware agents
    • Compare hidden enforcement (as in this paper) vs explicit capability disclosure in prompts/tools; test whether policy-awareness reduces timeouts, retries, and wrong-solution rates.
  • Dynamic/adaptive policies
    • Study mid-run policy changes, just-in-time privilege grants, per-tool whitelists, and approval workflows; design/benchmark agent negotiation protocols for permission requests.
  • Causality of denials
    • Instrument all runs (including failures) with fine-grained telemetry to causally link specific blocked operations to retries, workarounds, or abandonment using event-level and sequence models.
  • Failure-mode granularity
    • Decompose “wrong solutions” into finer categories (dependency substitution, data unavailability, path/visibility, logic errors), and map them to policy axes to guide targeted mitigations.
  • System overhead vs token cost
    • Quantify enforcement-induced system overhead (wall-clock, CPU, I/O, energy) separate from token spend; include tool execution time and non-LLM costs (e.g., storage egress, build time).
  • Model evolution and open-weight coverage
    • Re-evaluate as provider models update; expand local/open-weight models to decouple results from vendor safety layers and pricing, and to test on-prem inference under policy.
  • Budgeting and early-stop strategies
    • Explore adaptive stopping/retry policies, dynamic budget allocation, and plan-switching thresholds that minimize wasted spend under repeated denials.
  • Predictive calibration
    • Build pre-run predictors of policy tax using reference-solution compatibility, task capability tags (network/build/privilege needs), and historical blocked-action profiles to select models/harnesses and set budgets.
  • Benchmark design under policy
    • Provide policy-compliant task variants, tag capability requirements, and harden verifiers to avoid over-specification; define standard reporting that separates “blocked-by-design” from solvable tasks.
  • Reproducibility across environments
    • Measure sensitivity to cloud provider, kernel/cgroup versions, container runtime, and networking stack; publish seeds and environment manifests for exact replication.
  • Broader policy ladder
    • Add intermediate severities and orthogonal constraints (e.g., outbound DNS-only, egress rate limits, no ptrace, cgroup device restrictions) to derive full sensitivity curves.
  • Multi-agent and human-in-the-loop
    • Evaluate scenarios with human approval/grant flows and multi-agent delegation under policy; quantify utility–cost frontier with intermittent permissions.
  • Circumvention attempts and ethics
    • Detect, categorize, and measure attempts to tunnel, escalate, or solicit credentials; design and evaluate safeguards that prevent evasion without excessive utility loss.
  • Cross-run caching and warm-starts
    • Quantify how org-level caches (package, model, dataset) change success and cost under policy relative to cold-start isolated sandboxes.
  • Handling blocked-by-design tasks in evaluation
    • Develop principled metrics and filters for tasks inherently incompatible with the policy; automate pre-run detection of incompatibility.
  • Policy-compatible tooling
    • Test offline documentation, local mirrors, hermetic/nix-style builds, portable compilers, and vendored dependencies as interventions to reduce the policy tax.
  • Enforcement robustness
    • Validate non-bypassability of the enforcement (e.g., against SSH tunnels/ports, process escapes), document residual risks, and measure detection/alerting fidelity.
  • Timeouts and task budgets
    • Vary wall-clock budgets and retry limits under policy to estimate recommended budget multipliers and to separate true computation delays from policy-induced stalls.

Practical Applications

Immediate Applications

Below are deployable, concrete uses that leverage the paper’s findings, methods, and released tooling (Boundary-Bench) today.

  • Policy-graded agent bake-offs for procurement and deployment
    • What: Evaluate coding agents under your organization’s actual or planned security posture (non-root, egress allow-lists, read-only mounts) to pick the best success–cost trade-off for that policy.
    • Sector: Software/IT, Enterprise AI Governance, Security, Finance (cost control)
    • Tools/Products/Workflows: Boundary-Bench plugin on Terminal-Bench (or compatible benchmarks); success–cost Pareto reports per policy; routing sheets that map policies to preferred agents/harnesses.
    • Assumptions/Dependencies: Linux-based enforcement; containerized CI or sandbox infra; token pricing known; policy approximated by the provided NIST-mapped profiles.
  • Capacity planning and token budgeting under policy
    • What: Size budgets and SLAs acknowledging policy overheads (e.g., success losses up to 18.3 pp, cost inflation up to 167.3%, longer trajectories causing timeouts/wrong solutions).
    • Sector: Finance (FP&A for AI), Platform Eng, AgentOps
    • Tools/Products/Workflows: Cost calculators using measured multipliers; policy-aware retry/timeouts; dynamic budget ceilings per policy tier.
    • Assumptions/Dependencies: Stable token prices; representative task mix; same harness settings as in evaluation.
  • Agent routing by policy objective (success preservation vs. cost containment)
    • What: Choose agents differently depending on whether you value success retention (e.g., Grok-like behavior) or cost stability (e.g., Luna-like behavior) under hardening.
    • Sector: Software/IT, SaaS platforms, AgentOps
    • Tools/Products/Workflows: Policy-aware model selection matrices; per-policy routing rules in orchestrators.
    • Assumptions/Dependencies: Observed trade-offs hold on your workload; routing overhead is acceptable.
  • CI/CD “policy rehearsal” gates
    • What: Run end-to-end agent tasks in CI under multiple policy levels before merge or release to ensure workflows remain functional when security teams tighten controls.
    • Sector: Software Development, DevSecOps
    • Tools/Products/Workflows: Boundary-Bench in CI pipelines; pass/fail gates by policy tier; artifact uploads of blocked-action traces.
    • Assumptions/Dependencies: Test tasks approximate real workflows; Linux-native enforcement available in CI runners.
  • Allow-list and mirror planning using blocked-action telemetry
    • What: Use per-task blocked-action traces (egress denials dominate and persist) to design allow-lists, internal mirrors, and pre-staged assets that minimize retries/workarounds.
    • Sector: Security, IT Ops, Platform Eng
    • Tools/Products/Workflows: Internal artifact registries; curated package mirrors; approved domains seeded from telemetry.
    • Assumptions/Dependencies: Ability to host or mirror dependencies; stable dependency graphs for critical tasks.
  • Reference-solution compatibility triage for cost/risk hotspots
    • What: Pre-classify tasks as policy-affected vs. unaffected using the paper’s solvability audit approach to predict where success will drop and costs will spike.
    • Sector: AgentOps, Program/Project Management
    • Tools/Products/Workflows: A “compatibility scanner” that replays reference solutions under policy; risk dashboards tagging tasks as affected/unaffected/blocked-by-design.
    • Assumptions/Dependencies: Reference solutions exist and meaningfully represent success; tasks are reproducible.
  • Harness-agnostic policy regression testing for vendors and integrators
    • What: Validate that updated harnesses/tools don’t regress under hardened policies (the ablation showed harness swaps shift success).
    • Sector: AI Vendors, Systems Integrators
    • Tools/Products/Workflows: Boundary-Bench regression suites; per-release policy scorecards.
    • Assumptions/Dependencies: Access to multiple harnesses; consistent testbed.
  • Education and secure-by-default training modules
    • What: Teach developers and data scientists to build policy-compatible workflows (e.g., writable workspace use, no assumption of global write/egress).
    • Sector: Education, Corporate Training
    • Tools/Products/Workflows: Labs where students experience policy denials and learn mitigation patterns (local builds, cached toolchains, no root).
    • Assumptions/Dependencies: Classroom or lab compute with Linux containers.
  • Safer day-to-day local agent use
    • What: Run local coding agents in restricted modes (non-root, read-only mounts, curated egress) to reduce risk while maintaining utility.
    • Sector: Daily life, Individual developers, Small teams
    • Tools/Products/Workflows: Docker/Podman profiles implementing the paper’s policies; minimal writable workspaces; local package caches.
    • Assumptions/Dependencies: Comfort with containerization; occasional manual whitelisting.
  • Benchmarking with a policy axis for academic studies
    • What: Report model/agent results under graded policies to restore discriminative headroom and reveal success–cost trade-offs.
    • Sector: Academia, Benchmarking consortia
    • Tools/Products/Workflows: Boundary-Bench integration with existing benchmarks; per-policy leaderboards; failure-mode decomposition (timeouts vs. wrong solutions).
    • Assumptions/Dependencies: Benchmarks ship reference solutions or allow replay; shared infra for reproducibility.

Long-Term Applications

These opportunities will benefit from further research, scaling, or productization before broad deployment.

  • Policy-adaptive agents that proactively plan within constraints
    • What: Agents that detect policy denials early, reroute intelligently (e.g., build-from-source, use mirrors), and avoid dead-ends that cause timeouts or wrong solutions.
    • Sector: Software/IT, Agent platforms
    • Tools/Products/Workflows: “Policy-aware planners” trained on hardened traces; tool-use policies embedded in reasoning loops; adaptive retry budgets.
    • Assumptions/Dependencies: Access to denial signals/telemetry; training data from hardened runs; stable policy semantics.
  • Automatic pre-provisioning and artifact caching to offset cost inflation
    • What: Systems that learn which tasks inflate under policy and pre-stage compilers, datasets, and indices in the writable workspace or internal mirrors.
    • Sector: Platform Eng, MLOps, DevOps
    • Tools/Products/Workflows: Predictive cache warmers; workspace initializers; reproducible build artifact stores.
    • Assumptions/Dependencies: Accurate prediction of affected tasks; storage and SLSA/reproducibility guarantees.
  • Standardized “policy-graded” reporting requirements for procurement and regulation
    • What: Require vendors to publish success–cost curves at named policy levels (mapped to NIST families), not just unconstrained results.
    • Sector: Policy/Regulation, Compliance, Public Sector, Healthcare/Finance (regulated)
    • Tools/Products/Workflows: RFP templates including policy-graded benchmarks; conformity attestations; third-party audits.
    • Assumptions/Dependencies: Consensus on reference policies; accepted mappings to control families; independent labs.
  • Cross-domain benchmarks with enforced policy axes (web, IDE, OS automation)
    • What: Extend Boundary-Bench’s approach beyond Terminal-Bench to WebArena/OSWorld/SWE-bench with graded network/FS/privilege profiles.
    • Sector: Academia, Industry consortia, Tool vendors
    • Tools/Products/Workflows: Policy-enforcing harnesses for browsers/IDEs; unified scorecards across domains.
    • Assumptions/Dependencies: Deterministic enforcement for GUIs/browsers; realistic yet standardized policies.
  • Real-time agent routing by marginal utility under policy
    • What: Orchestrators that switch models/harnesses mid-run when encountering denials, trading cost for success as needed.
    • Sector: AgentOps, SaaS orchestration
    • Tools/Products/Workflows: Online estimators of success vs. token slope; “escape hatch” routes to higher-robustness bundles.
    • Assumptions/Dependencies: Latency headroom; reliable online metrics; cost governance.
  • Verifier repair and solvability-witness toolchains as first-class benchmark features
    • What: Benchmarks ship solvability witnesses for hardened policies and guard against over-specified verifiers that mask true success.
    • Sector: Academia, Benchmark maintainers
    • Tools/Products/Workflows: Witness CI; verifier linting; contributor guidelines for additive-only checks.
    • Assumptions/Dependencies: Community maintenance; expanded CI cost budgets.
  • Security analytics from blocked-action telemetry
    • What: Turn denials into risk signals (e.g., anomalous egress attempts), with dashboards highlighting hotspots and suggesting allow-list changes.
    • Sector: Cybersecurity, SOC, GRC
    • Tools/Products/Workflows: “Agent Denial Analytics” platform; correlation with DLP/IDS; policy-change simulators.
    • Assumptions/Dependencies: High-fidelity logging; privacy/compliance handling; integration with existing SIEM.
  • Model and harness co-design for hardened efficiency
    • What: Jointly tune models and toolchains to minimize policy-driven overhead (e.g., fewer network-dependent steps; local-first build strategies).
    • Sector: AI Vendors, IDE/agent toolmakers
    • Tools/Products/Workflows: Bench-to-design loops using success–cost gradients per policy; harness plugins for offline-first operations.
    • Assumptions/Dependencies: Access to model/harness internals; willingness to optimize for constrained environments.
  • Compliance-aware developer experiences
    • What: IDEs and agent IDEs that warn when a plan will hit policy walls, suggest compliant alternatives, and estimate added cost/time.
    • Sector: DevTools, Education, Enterprise IT
    • Tools/Products/Workflows: “Design-for-hardening” UX; inline policy linting for plans; local rehearsal runs.
    • Assumptions/Dependencies: Policy introspection APIs; plan analysis; UX integration.
  • Domain-specific hardened runbooks for regulated sectors
    • What: Pre-vetted workflows (e.g., healthcare code analysis, financial report parsing) that operate within strict egress/privilege constraints with predictable costs.
    • Sector: Healthcare, Finance, Public Sector
    • Tools/Products/Workflows: Sector playbooks; certified mirrors/registries; token and latency SLAs per policy tier.
    • Assumptions/Dependencies: Sector-specific compliance review; controlled dependency sets; auditability.

Notes on general feasibility

  • Boundary-Bench maps mechanisms to NIST SP 800-53 families but does not claim compliance; use it to measure utility/cost under policy, not to certify security.
  • Results are benchmark- and bundle-specific; replicate on your workloads, policies, and harnesses before committing to production choices.
  • Provider-side safety interventions can affect measured success and may differ by deployment route; include them in end-to-end evaluations.

Glossary

  • Ablation study: An experiment that isolates the contribution of components by swapping or removing them. "Model-harness ablation study."
  • Access controls (AC-3): NIST controls limiting which subjects can access which resources. "access, information-flow, and process-isolation controls (AC-3, AC-4, SC-39)"
  • Affected subset: Tasks whose canonical reference solution breaks under policy and need an alternative to pass. "We call these the unaffected (50) and affected (32) subsets."
  • Allow-list: A security list specifying destinations that are explicitly permitted. "a fixed network egress allow-list"
  • Block-and-revise gate: A runtime mechanism that blocks unsafe actions and asks the agent to revise. "under an internal block-and-revise gate"
  • Blocked action: An attempted operation that is denied by enforced policy. "A \emph{blocked action} is one denied operation, counted from verified-complete evidence only (Appendix~G)."
  • Blocked by design: Tasks that are unsolvable because their requirements directly conflict with the enforced policy. "Seven tasks are blocked by design: no policy-compliant solution exists."
  • Boundary-Bench: The framework/plugin that enforces graded security policies for evaluation. "We release Boundary-Bench, an open-source hardening plugin enabling policy-constrained evaluation of coding agents on Terminal-Bench and compatible benchmarks."
  • Boundary protection (SC-7): NIST controls securing network boundaries against unauthorized traffic. "boundary protection (SC-7) on the network axis"
  • Cloud sandbox: An isolated cloud environment used to run each task safely and reproducibly. "Each trial runs in an isolated cloud sandbox (Daytona)"
  • Compliance-scored benchmarks: Evaluations that score whether agents follow policies, without enforcing them at runtime. "Compliance-scored benchmarks check whether agents follow stated policies, but neither enforce them at runtime nor measure their operational cost"
  • Cost-aware evaluation: Reporting task success jointly with inference or operational cost. "cost-aware evaluation reports success jointly with inference cost, for example as a Pareto frontier"
  • Cost multiplier: Per-task cost under policy divided by cost under control, averaged over tasks. "At task level we use the cost multiplier: a bundle--task pair's mean cost over completed (PASS or FAIL) runs under a policy divided by its mean control cost, averaged with equal weight across pairs."
  • Effective-robustness lens: A perspective comparing performance under distribution or condition shifts against a baseline. "We draw qualitative inspiration from the effective-robustness lens"
  • Empirical cumulative distributions: Nonparametric summaries showing the cumulative probability of observed costs. "Empirical cumulative distributions of per-run cost (USD, logarithmic scale)"
  • Enforcement boundary: The interface where policy restrictions are applied and denials occur. "we quantify agents' blocked-action exposure at the enforcement boundary"
  • Egress denials: Blocks of outbound network connections under the enforced policy. "Egress denials lead on every measure"
  • Filesystem sandboxes: Constrained filesystem views/workspaces exposed by agent harnesses. "filesystem sandboxes, and run profiles."
  • Gated route: A serving path where safety gating or model fallback alters which model actually handles requests. "so its results describe the gated route rather than Fable 5 alone."
  • Hardening: Applying security restrictions to reduce capabilities and attack surface. "Hardening is never free but far from uniform"
  • Hardened environments: Execution settings where policy restricts observation, access, or execution. "We call such settings hardened environments: execution environments in which policy restricts what an agent can observe, access, or execute."
  • Hierarchical-bootstrap: A resampling method respecting multi-level structure to form uncertainty intervals. "95\% intervals from 10{,}000 hierarchical-bootstrap replicates."
  • Information-flow controls (AC-4): NIST controls governing permitted flows of information between components. "access, information-flow, and process-isolation controls (AC-3, AC-4, SC-39)"
  • Least privilege (AC-6): Granting only the minimum permissions necessary to perform tasks. "least privilege (AC-6) on the privilege axis."
  • Model–harness bundle: The paired model and its agent runtime/harness evaluated as a single unit. "The evaluated unit in all experiments is a frozen model-harness bundle"
  • Native Linux mechanisms: OS-level features (e.g., mounts, users, proxies) used to enforce policy. "enforced by native Linux mechanisms."
  • Network egress: Outbound network communication from the agent/runtime. "We model policies on three axes: network egress (N), filesystem scope (F), and privilege (P)."
  • NIST SP 800-53: A catalog of security and privacy controls used to map policy axes and mechanisms. "These mechanisms correspond to access-control and boundary-protection families in NIST SP 800-53"
  • NIST-derived high: The strict policy level that simultaneously restricts egress, filesystem, and privilege. "NIST-derived high restricts all three axes together"
  • Non-root: A policy level where the agent runs without administrative privileges. "Non-root drops root privilege only"
  • Open-source hardening plugin: A publicly released tool that adds enforced security policy to benchmarks. "an open-source hardening plugin"
  • Open-weight: Models available as open weights rather than purely via proprietary APIs. "The open-weight bundles evaluated on Terminus-2 account for most of the additional timeouts"
  • Pareto frontier: The set of non-dominated trade-offs between success and cost. "we represent the resulting trade-off as a success--cost Pareto frontier"
  • Policy-constrained evaluation: Benchmarking where runtime policies are enforced during agent execution. "enabling policy-constrained evaluation of coding agents"
  • Policy denial: A refused action due to enforced policy restrictions. "a policy denial can trigger retries, workarounds, or abandonment"
  • Policy levels: Discrete settings of enforcement severity used to evaluate agents. "three nested policy levels"
  • Pre-flight probes: Checks run before trials to confirm that policy restrictions are in effect. "Before each run, pre-flight probes confirm every restriction is active"
  • Privilege lockdown: Comprehensive removal of capabilities and escalation paths. "a full privilege lockdown"
  • Process-isolation controls (SC-39): Controls that prevent unsafe interaction between processes. "access, information-flow, and process-isolation controls (AC-3, AC-4, SC-39)"
  • Read-only filesystem: Filesystem configuration that prevents writes outside a small allowed workspace. "a read-only filesystem outside a dedicated small writable set"
  • Reference-solution compatibility: Whether the benchmark’s canonical solution still passes under policy. "A task's reference-solution compatibility, computable before any agent runs, therefore anticipates where a policy will cost both money and success."
  • Robustness Pareto frontier: The best trade-offs between success loss and cost inflation under restriction. "a robustness Pareto frontier: the bundles offering the best trade-off between success loss and cost inflation under restriction."
  • Routing and cascade methods: Techniques that select among models/paths to balance performance and cost. "Routing and cascade methods"
  • Runtime perturbation: A change to allowed observations or actions during execution. "Security-policy enforcement is itself a structured runtime perturbation"
  • Solvability audit: Procedure to determine which tasks remain solvable under the strictest policy. "extending the solvability audit to further benchmarks"
  • Solvability witness: A verified trajectory showing a task can be solved under policy. "gains a solvability witness."
  • Success–cost trade-off: The relationship between task success rates and the cost to achieve them. "success--cost trade-offs of agents in deployed enterprise settings."
  • Task accessibility: Whether any evaluated agent can solve a task under a given policy. "This identifies task accessibility and cases where agents succeed through alternative trajectories when the canonical trajectory is blocked."
  • Tool-chain: A set of tools built or installed to complete a task. "rebuilds a tool-chain from source"
  • Unprivileged user: An account without administrative permissions used to execute the agent. "the agent process runs under an unprivileged user that cannot re-escalate."
  • Wall-clock budget: The time limit allocated for a task’s execution. "relative to its task's wall-clock budget"
  • Workaround construction: Extra steps the agent takes to bypass blocked paths by rebuilding tools or substituting data. "The mechanism is almost exclusively workaround construction (97\%)"
  • Verifier over-specification: Evaluation checks that require incidental details not essential to the task goal. "Verifier over-specification, where assertions demand incidental details a task never requires"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 7 tweets with 275 likes about this paper.