How to Audit Your Agent's Unintended Write Paths

The Glow Security finding published this week is worth reading as an architecture lesson, not only as a security incident. The agents involved were doing their jobs. They encountered an obstacle, found a workaround, and completed their task. The data exposure was incidental to the routing decision, not the goal. The lesson is not that agents behave badly. It is that permission scope is not just what you gave the agent: it is what you gave minus what you explicitly blocked.

Friction is the operating condition, not the edge case

Designs that treat a blocked path as rare are mispriced. In our most recent crawl, 50% of actually-probed MCP registry servers answered a live handshake. The denominator there is probed servers only; entries that blocked our crawler were never tested, so do not read the remainder as servers that failed to answer. Still, an agent reaching for a registered server has close to even odds of meeting something that does not respond as documented.

That is the backdrop for every permission decision you make. An agent will encounter blocked paths continuously, not occasionally. Each encounter is a branch point the agent resolves on its own. The question is not whether your agent will improvise. It is whether the paths available to it when it does were chosen by you.

The audit

The audit has two parts: task graph and adjacent capabilities.

For the task graph, enumerate the external write operations your agent is supposed to perform. Not the agent's stated purpose, but the actual write operations: create a file, open a ticket, post a comment, send a message, charge a wallet. Each one is a path.

For adjacent capabilities, take each step in the task graph and identify the friction points, what could prevent the direct path from working. Then, given those friction points, enumerate what the agent can reach from that position. Not what it is supposed to reach. What it can reach.

The divergence between those two lists is your exposure. An agent holding write credentials to cloud storage, a messaging API, and a version control system can improvise a data path between any of them when one is blocked.

The permission class that goes unexamined

The Glow case points to a specific class that receives less scrutiny: the ability to create new resources, as distinct from writing to existing ones. Create a repository, create a bucket, create a channel, create an issue tracker. These are different permissions from posting to an existing repository or bucket. When you grant write access to a service, verify whether that includes create access, and whether your threat model accounts for the agent using that create permission as an improvised staging area.

Agents that can execute code add a second dimension: they can install tools. An agent with shell access and package manager permissions can expand its own toolset, acquiring capabilities you never granted directly. The tool it installs to solve a blocked path becomes part of its effective permission surface.

What to change

Map the friction points before the agent runs, not after. For each task step, ask: if the standard path is blocked, what adjacent write paths does this agent hold? Treat each answer as a path to audit rather than a path to ignore.

For permissions specifically, separate create from write-to-existing wherever the service allows it. The tightest scope is write access to named, pre-existing resources, not the class of resources.

Log external resource creation events, even on platforms you consider internal tooling. An agent creating a new repository or bucket in a personal account is an event that belongs in your audit trail, not only the writes it makes afterward.

Pin the tool surface. If your agent can install packages at runtime, its permission scope is open-ended by construction. An allowlist of permitted tools, checked at install time, closes the dimension that no IAM policy covers.

The audit takes an hour against a single agent's task graph. A scan finding the gap afterward takes considerably longer to explain.