Many agent runtimes give the agent a tool for editing its own configuration. Some settings grant abilities, such as enabling a tool. Others set the agent's limits: where it may write, who may message it, which address it listens on, how callers authenticate, and the gate that blocks risky writes. We measure how often models widen those limits while handling ordinary requests, and how well two kinds of defence hold: a prohibition in the system prompt, in three wordings, and a check at the point of writing that we call a containment floor. Every case records whether a protected write was attempted and whether it was saved, read from the tool's arguments and from the file rather than from the model's reply. With no defence, a frontier model saved a protected value on 25 of 72 requests, often when the request never named the field. A prompt that listed the protected field names stopped every request that used those names and did not reduce writes on requests that only described the goal; a prompt that described the forbidden effects did the reverse. With the floor, 0 of 167 protected writes were saved while 65 were attempted. A single-pass pilot on two further models shows the same pattern. We draw four lessons for evaluating agent safeguards: count attempts beside outcomes, test a prompt defence with requests written in a different vocabulary from the prompt, check that a zero means the safeguard fired, and log what the harness sends to the model, because a request-ordering defect in our own runtime was invisible in the transcripts and was found again, independently, by a later benchmark.

翻译：暂无翻译