Nobody audits your guardrails except the changelog

An ops lead can hand an AI agent a folder of client files, a database login, and an hour of unsupervised time, then go sit in a meeting. The thing that makes that defensible is not the model. It is a settings file, a short list of what the agent may never read, never write, and never run, and that file is what replaced the twenty minutes of sitting there clicking approve on every individual command. Before the file existed, the only other option was the security review that no forty person company was ever going to pay four figures for. Between September 6 and September 10, roughly ten separate fixes shipped in the Claude Code changelog describing situations where the rule in that file was not the rule that actually ran.

None of them were announced as a security story. They were bullets, in the middle of long release notes, sitting between a spinner fix and a VS Code theme bug.

What actually got repaired

Read them together and they stop looking like unrelated bugs.

A deny rule written against a directory did not apply when the path was given by its real location instead of the symlinked one, which on macOS covers /etc, /tmp and /var, and on Linux covers /bin. So a rule saying the agent may never touch /tmp was enforced against the spelling you wrote and not against the place it points. Bash commands went the other way, ignoring deny rules written in the symlinked spelling. Either way, one of the two ways of naming the same directory worked and the other quietly did not.

A Read or Edit deny rule did not apply when a command the permission checker cannot parse, an env -C or an eval, sat on the same line. The checker could not read the line, so the line went through.

Managed settings that administrators use to constrain a whole company, the lists naming which hook URLs and which plugin channels are permitted, were admitting everything rather than nothing when the file could not be read. That is the classic shape of this failure. A policy that cannot be loaded should refuse; this one waved traffic through, and it took a changelog line to say so.

The Bash sandbox was describing confinement it was not providing, not to the user but to the model itself. The fix removed unenforced path lists from the instructions when filesystem isolation is off, and stopped strict mode from claiming that commands can never run outside the sandbox. The agent had been reading a promise about its own environment that was not accurate, which is a strange failure to think about and a worse one to build on.

Plugin and marketplace errors were printing tokens and passwords lifted out of git source URLs. Separately, /mcp and /plugin server details, plus claude mcp list and MCP login errors, were printing secrets after resolving the ${VAR} placeholders in MCP configs. The whole point of writing ${HUBSPOT_TOKEN} in a config instead of the token itself is that the token does not end up somewhere it can be read. It was ending up on screen, and on screen means in a screenshot, in a support ticket, in a shared terminal recording.

A plugin path containing a backslash could get past the containment check on macOS and Linux. A respawned in-process teammate could pick up tools or a system prompt from a same-named agent file sitting in a folder you had never trusted.

And one change is not a fix at all, it is a redefinition worth catching: plain WebFetch deny and ask rules no longer apply to Artifact tool reads and updates. If you wrote a WebFetch deny rule at some point and assumed it covered everything that reaches out to the network, it now covers less than it did, and the release note is the only notification you get.

Why this lands hardest on the person who is not an engineer

Think about who actually configured one of these files.

A RevOps manager builds a CRM enrichment job. It needs the CRM, so a private app token goes into an MCP config. It needs a spreadsheet, so a service account goes in next to it. They read a setup guide, they add a couple of deny rules around the folders holding client contracts, they turn on the sandbox because a post told them to, and then they let the thing run while they do something else. That is a completely reasonable Tuesday, and it is exactly the workflow this series keeps saying is now available without an engineering ticket.

Every one of the failures above sits inside that workflow. The token is in the MCP config. The client contracts are in a folder guarded by a deny rule. The sandbox is on. The person doing this has no way to tell that the deny rule missed a spelling, or that the config is going to print the token in an error message, or that the sandbox instructions overstated what the sandbox was doing.

An engineer has a partial defense here, which is suspicion. Somebody who has spent a decade writing software has been burned by a path-matching bug before and half expects one. The non-engineer builder has the opposite instinct, and a reasonable one: the settings file is the product's own safety feature, documented by the vendor, recommended in the vendor's own guides. Treating it as though it works is not naivety. It is reading the documentation.

The uncomfortable part is what happens after the fix ships. You update, the hole closes, and nothing in your session tells you that for the preceding stretch of weeks your rule was not doing what it said. There is no retroactive log. There is no line in /status reading "this rule was not being enforced until Tuesday." The state of your guardrail before the patch and after the patch look identical from where you sit.

The honest take

Here is the part that does not get fixed by a release, and it is the reason this is a story at all rather than a routine patch note.

You cannot test a deny rule. Not really. The only way to verify that a rule blocking access to a folder actually blocks access to that folder is to instruct the agent to go into that folder and see what happens, and if the rule has a hole, you have just performed the thing you were trying to prevent. Every other control in an operator's life can be checked cheaply. You can send yourself a test invoice. You can fire a test webhook. You can put a fake record in the CRM and watch the workflow move it. A permission boundary is the one control whose test case is the incident.

Which means the audit is outsourced. Somebody at the vendor finds the gap, fixes it, and writes a sentence about it. That sentence is your audit. It is the entire audit. And it arrives in a document most people building this way have never opened, in the middle of ninety other bullets about terminal rendering.

The vendors are not hiding this, to be fair to them, and the second thing worth reading this week is documentation rather than a changelog. The Claude Code sandboxing page states it plainly: "Sandboxing reduces risk but is not a complete isolation boundary. Review the limitations below before relying on it as a hard security control." The limitations that follow are specific and sobering. The network proxy makes its allow decision from the hostname the client supplies without inspecting TLS, so allowing a broad domain can open a path for data to leave. Allowing the wrong Unix socket, the Docker one being the named example, effectively hands over the host. And the line that should stop a RevOps reader cold: sandboxed Bash commands inherit the parent process environment by default, including any credentials sitting in it. The sandbox constrains which files a command can open. It does not, unless you configure it to, take away the keys.

Cursor's sandbox reference draws the same distinction in its own words, treating allow and deny rules as pattern-based workflow controls rather than the security boundary, with the sandbox as the layer doing the actual constraining. Cursor is also explicit that the classifier deciding which actions can skip a prompt is non-deterministic and best-effort convenience rather than a boundary, and says not to point it at production credentials. Two vendors, two documentation sets, same admission. The settings file is a statement of intent. The sandbox is the mechanism, and the mechanism has a published list of holes.

So the accurate mental model is not "I configured it, therefore it is safe." It is closer to a lock on an office door. It stops the ordinary case, it is absolutely worth having, and it is not what you would rely on for the thing you cannot afford to lose.

Where the ceiling is this week, and it moved the wrong way

This series asks every week what a non-engineer can ship that they could not ship a month ago. The honest answer for this particular week is: nothing new, and that is the story.

What moved is the ceiling, and it moved down, or more precisely it became visible at a lower height than people thought. The ceiling on building this way is no longer the model's ability to write the integration. That stopped being the constraint a while ago. The ceiling now is permission configuration, a discipline with real depth, almost no teaching material aimed at non-engineers, and a failure mode that is silent by construction.

That is an unusual place for a ceiling to sit, because it is not a skill the tools are racing to remove. Every other friction point in this stack gets deleted eventually. The terminal went away. The GitHub account went away. The deploy step went away. Permission configuration is going the other direction: more settings keys, more precedence rules, more interaction between managed policy and project policy and user policy, and a week like this one where the interactions between them turn out to have been wrong in ten places at once.

There are three things worth doing about it, and they are all cheap, which is the only reason to mention them.

Update the tool, and specifically update it after a week where the release notes are dense, because the density is the signal. Keep the credentials that matter out of the environment your agent inherits rather than relying on a file rule to keep the agent away from them, since a rule about a path and a variable already loaded into memory are different problems. And keep the blast radius small enough that a guardrail failure is survivable: point the agent at a copy of the client folder rather than the client folder, give it a scoped token rather than the admin one, and let it work in a place where the worst version of the afternoon is annoying instead of expensive. None of that requires understanding the symlink bug. It just requires assuming one exists.

The reason this matters beyond a single week is that the trajectory is set. Agents are going to run longer, with more connected systems, with fewer prompts, because that is what everybody involved wants. The approval prompt is being retired on the argument that humans were not catching much anyway, and there is real evidence for that argument. But the replacement for the human is a configuration file, and this week is a reminder that the configuration file is software, written by people, with bugs in it, and that the software has no idea when it is wrong.

The guardrail you cannot test is a guardrail you are trusting, not a guardrail you are using, and trust is the thing you were supposed to be automating away.