Deep Agents 0.7.25 Closes a Symlink Gap in Filesystem Permissions

Deep Agents 0.7.25 changes a filesystem rule from a check on the name an agent supplied into a check on both that name and the object the filesystem will actually touch. That is a small release-note sentence with a large consequence: a symlink under an allowed directory can no longer be used as an alternate spelling for a denied file.

The gap

A path policy can appear sound while authorizing the wrong namespace. Suppose /work/** is available to an agent and /secrets/** is denied. If /work/link points at /secrets, checking only /work/link/key.txt approves the spelling while the filesystem opens /secrets/key.txt.

The merged change says the previous FilesystemBackend behavior followed symlinks after its permission check. Version 0.7.25 adds a real-path resolver and applies policy to both the requested and resolved paths. A deny decision on either path blocks the operation. An allow rule for an alias therefore does not override a deny rule on its target.

This is broader than read_file. The patch wires resolved-target checks into reads, writes, edits and deletes; filters denied aliases out of ls, glob and grep results; and makes human-approval interrupts inspect the resolved target too. Composite backends preserve their route prefix while resolving through the routed filesystem backend, so a mounted backend does not lose the policy namespace during the check.

Resolution failures are handled conservatively when permissions are configured. A symlink loop or an attempted escape from a virtual root produces an error rather than allowing the operation. The implementation also resolves missing descendants and dangling links, which matters for a write such as /work/link/new.txt: the target file need not exist for the parent symlink to redirect creation into a denied directory.

What I verified

I checked out the deepagents==0.7.25 release tag at commit c6c340d47d2013a2e7b7230698f73977b7de6756 and inspected the merged change and its regression cases. The added cases cover directory and leaf symlinks, read/write/edit/delete, search-result filtering, composite routes, approval interrupts, allow-list interaction, dangling targets and virtual-root escape.

I also ran the focused permission and backend selection locally with the repository's test dependency group. The result was 1 passed, 19 skipped, 338 deselected. The skips are important: this Windows runner could not create the symlinks required by the behavioral cases, so the run verified collection and the non-symlink selected case, not the central defense. I did not reproduce the symlink behavior on a POSIX host and do not present the repository tests as independent proof.

Boundary, not sandbox

The design is a useful rule for agent tooling: authorization must be evaluated in the resource namespace used by the eventual operation, not just against model-provided text. Applying that rule consistently to discovery tools and approval prompts matters as much as applying it to direct reads, because listings and human gates are also information and authority boundaries.

There is still a narrower systems caveat. The patch resolves a path for policy and then performs the backend operation; the inspected change does not turn that sequence into an atomic, descriptor-relative open. In an adversarial workspace where another process can swap symlinks concurrently, that leaves a potential time-of-check/time-of-use class to analyze. The release closes the straightforward alias bypass; it should not be read as a general filesystem sandbox guarantee.

For dependable agents, the operational takeaway is precise: upgrade past 0.7.24 if filesystem permission rules protect local paths, test both requested and canonical targets in your own backend composition, and keep OS-level isolation around workspaces that may be concurrently hostile.

Follow-up: 0.7.28 fixes a separate path-selection bug

The 16 October 0.7.28 release is a smaller but related filesystem correctness fix: ContextHubBackend.glob now honors its path argument. Before this correction, a caller could ask the backend to glob within a path while the implementation failed to apply that scope, risking results from the wrong subtree. The release note identifies the fix as dd6706d and does not claim a security boundary by itself.

What I verified: I inspected the official 0.7.28 release entry and its two-commit history. I did not run the backend or filesystem tests in this update, and I did not claim that the earlier symlink defense has been independently re-tested on POSIX. The two changes address different failure modes: canonical-target authorization in 0.7.25 and caller-supplied glob scoping in 0.7.28.