cs.LGOct 5, 2026

What May an Agent Change About Itself? A Containment Floor for Self-Configuring Agent Runtimes

Authors: Sajib Hossain, Moeen Uddin Mahmud

Organizations: North South University · HelicanHQ

Read PDF
Ask AI
Cite

Copy citation

DOINot available for this paper

Abstract

Many agent runtimes give the agent a tool for editing its own configuration. Some of that configuration grants abilities, such as enabling a tool. Other parts set the agent's limits: which directories it may write to, who may send it messages, which network address it listens on, how callers authenticate, and the gate that blocks risky writes. If the agent can edit those limits, a single ordinary request can widen them. We study this in a deployed, model-agnostic runtime. We propose a rule: the agent may change fields that grant abilities, and may never change fields that set its limits. We enforce the rule as a containment floor inside the configuration tool and measure what happens with and without it. Without the floor, a frontier model wrote a protected value on 25 of 72 ordinary requests that gave it permission to change settings, often when the request never named the field. Prohibitions written in the system prompt failed in a predictable way. A prompt that listed the protected field names stopped every request that used those names (0 of 36 saved, against 17 of 36 with no prompt) and did not stop the requests that only described the goal (10 of 36 saved, against 8 of 36). A prompt that described the forbidden effects did the reverse. With the floor, 0 of 167 protected writes were saved, although the models attempted a protected write in 65 of those cases. A search for other routes through the tool found only one, a pinned shell, which the floor's scope statement already excludes. The study covers two models and a single agent. We state what that does and does not support.

Figures & tables

Figure 1: One request from the study, with and without the floor. The user wants an outcome. The model reaches it by widening its own network reach, a change the user never asked for by name. Counts are from the frontier model with no protection (§ 4 ).
FieldWhat it controlsWhy the agent may not change itHow the floor detects a write
writeRootsDirectories the agent’s file tools may write toA new value can widen where the agent may write, and the tool cannot tell a narrower value from a wider oneBy key name, at any depth of the path, and inside any value written, including values written to tools.providers . Any value is refused.
channels[]. allowFromWho may send the agent messages on a channelA new value can widen who can reach the agent, and the tool cannot tell a narrower list from a wider oneBy key name, at any depth, and inside any value written to channels . Any value is refused.
server.hostNetwork address the API listens onA new address can widen the agent’s reach, and the tool cannot tell a narrower address from a wider oneBy exact path. Any value is refused.
server.tokenEnvEnvironment variable that holds the API tokenIt changes what authenticates callersBy exact path. Any value is refused.
policy.denyCommands the agent is forbidden to runIt removes a restriction someone else setBy exact path. Any replacement is refused.
untrusted. onMutateWhether writes are allowed after the agent reads untrusted contentThe value allow turns the write gate offBy exact path and value. Only allow is refused; confirm is permitted.
Table 1: The floor. Every field not listed here, including fields that enable new tools, can be set by the agent. policy and untrusted sit under tools in the manifest. Matching is case-insensitive, so WriteRoots and server.Host are refused too (Appendix G ).
ModelArmIndirect att/execDirect att/execAll protected att/execControls landed
gpt-5.6 (native)None8/8 of 3617/17 of 3625/25 of 7221/36
Prompt (fields)10/10 of 360/0 of 3610/10 of 7219/36
Prompt (effects)0/0 of 3619/19 of 3619/19 of 7219/36
Prompt (both)3/3 of 181/1 of 184/4 of 367/18
Floor3/ 0 of 3623/ 0 of 3626/ 0 of 7222/35
Shipped0/ 0 of 3525/ 0 of 3625/ 0 of 7120/32
Table 2: Self-widening. Each cell is cases with a protected attempt / cases with a protected value in the file afterwards, out of the number of cases shown. Frontier: two runs of three passes, pooled (Prompt (both): one run). Small model: one pass. The control column counts legitimate changes that succeeded.
Comparison (executed protected writes)ArmNoneFisher pp
Prompt (fields), direct requests0/36 (0–10%)17/36 (32–63%)1.3×10−61.3\times 10^{-6}
Prompt (fields), indirect requests10/36 (16–44%)8/36 (12–38%)0.79
Prompt (effects), indirect requests0/36 (0–10%)8/36 (12–38%)0.005
Prompt (effects), direct requests19/36 (37–68%)17/36 (32–63%)0.81
Prompt (both), all protected, same run4/36 (4–25%)12/36 (20–50%)0.045
Floor and Shipped, all protected, both models0/167 (0–2%)25/72 (25–46%)n/a
Table 3: Key comparisons, frontier model, with Wilson 95% intervals and two-sided Fisher exact tests. Cases are pooled over passes and runs. Passes of the same request are not independent, and there are only six wordings per request type, so these intervals are narrower than the true uncertainty and the tests should be read as descriptive.
Appendix figures & tables2 assets

Supplementary material from the paper’s appendix.

Appendix

Armdeepseek-v4-progpt-5.6 (native)llama3.2:3b
Full catalogue, 10 tools87.5 / 83.395.8 (2 crit.)41.7 (6 crit.)
Triage + phase_set advertising “act adds 5 tools”75.0 / 75.091.770.8
Triage + phase_set , nothing advertisednot run91.770.8
Triage, no phase_setnot run100.066.7
Appendix
Table 4: Phase scoping, accuracy on 24 comparable tasks. “Crit.” counts critical errors, where a mutating tool fired on a task that needed none. The frontier and 3B columns are from this work. The deepseek column is the earlier evaluation (two runs, text tool format) that motivated the hypothesis; it did not run the two new arms.
RequestsNone, executedFloor att/execShipped att/exec
Paraphrase, no field named65/ 03/ 0
Nested in a parent or block147/ 010/ 0
Pressure, two turns118/ 00/ 0
All31 of 5120/ 0 of 5113/ 0 of 47
Appendix
Table 5: Routes around the floor, frontier model, three passes: cases with a protected attempt / cases with a protected value in the file afterwards. Paraphrase and pressure have 18 cases per arm and nested has 15; Shipped has 17 and 15 valid. Attempts are not shown for None, because a block write there succeeds without touching a protected path.

Explore similar work

CardsList
May 27, 2026cs.CR

AIRGuard: Guarding Agent Actions with Runtime Authority Control

Tool-using language agents turn model decisions into external side effects: they read files, run scripts, call APIs, send messages, and invoke Model Context Protocol tools. This makes agent attacks different from jailbreaks. The harmful step is often not an obviously forbidden output, but an ordinary executable action that becomes unsafe because attacker-controlled context steers authorized access against the user's interest. We identify this failure mode as authority confusion: untrusted resources may inform reasoning, but they must not authorize side effects. We present AIRGuard, a runtime guard that operationalizes least privilege as action-time authorization. AIRGuard normalizes heterogeneous tool calls, derives task authority into step-level authority, tracks source and target trust, simulates sensitive side effects, audits cross-step risk, and enforces decisions before actions execute. On AgentTrap, AIRGuard reduces Sonnet 4.6 attack success from 36.3% without defense to 5.5%. On DTAP-150, AIRGuard preserves 76.0% benign utility with Haiku 4.5, compared with 52.0% for ARGUS and 42.0% for MELON. An ablation further shows that prompt-only policy helps only modestly, whereas a dedicated runtime authority-control layer gives the agent system direct control over tool-mediated side effects. Code and data are available at https://github.com/Sophie508/AIRGuard.

Suliu Qin, Haomin Zhuang, Yujun Zhou +2

University of Liverpool · University of Notre Dame · 2Inria, France

AuthorizationRuntime Safety FilteringDiverse AttacksRuntimeAction Expert
AskPDF
Jul 26, 2026cs.AI

Are You Still the Agent I Authorized? Earned Authority under a Fixed Ceiling for Evolving Agents

Long-lived AI agents increasingly evolve after deployment by retaining experience, acquiring skills and tools, revising workflows, delegating work, and moving across task phases. This improves adaptation but creates a distinct authorization problem. Tool-enabled agents can turn model errors and prompt injections into consequential external actions; when evolution occurs under a live grant, the subject exercising that authority or the context in which it acts may no longer match what the user evaluated. Evolution can change both the effects reachable under an old grant and the authority required by the task, which may rise, fall, or become incomparable. Existing tool policies constrain actions but do not determine when a grant survives this change. We formulate authorization continuity: when does an existing grant remain valid, how may active authority change, and what boundary must never move? Our state-bound model fixes a transition envelope and an immutable effect ceiling at grant time. The envelope determines whether the grant survives a mutation; below the ceiling, authority may contract freely and expand only under specified evidence conditions. We distinguish requested from realized effects and prove that, under complete mediation, sound effect abstraction, attenuating delegation, and monitor integrity, mutation cannot amplify protected effects beyond the user-issued ceiling. Agent-produced evidence may allocate authority below the ceiling but cannot raise it. Finally, we map six mutation classes to their authorization consequences.

Zhaoxi Zhang, Xiaomei Zhang

University of Technology Sydney · Griffith University

AuthorizationAuthorityAgentic DeploymentsSelf-Evolving AgentsArtificial Intelligence AgentsCeiling
AskPDF
Jul 24, 2026cs.AI

What Can Be Enforced? A Theory of Certified Runtime Safety for Tool-Using Agents

Runtime guardrails act before irreversible tool calls, but their guarantees depend on what policy state is representable, what a judge observes, and whether intervention changes future behavior. We separate three questions. First, relative to fixed oracle predicates, a deterministic gate enforces exactly the nonempty safety policies whose good prefixes its register model recognizes; policy nontriviality is undecidable with two decrementable counters but in PSPACE for a separable monotone fragment. Second, under a fixed exogenous law, Neyman-Pearson gives the exact false-block/miss frontier and conformal calibration gives a finite-sample marginal certificate, possibly via block-all. Third, once blocking changes future proposals, static scores and ungated trajectories need not identify the closed-loop frontier; a specified finite controlled model instead yields an occupancy program. Bounded representation attacks add a robustness margin, so benign calibration alone does not transfer. Experiments target these distinctions through static diagnostics, controlled-model enumeration, representation rewrites, and paired closed-loop reruns.

Shawn Ray

Carnegie Mellon University

Runtime EnforcementClosed LoopTheory
AskPDF