A coding agent has a read_file tool scoped to /work/repo. The wrapper checks that the requested string begins with /work/repo/. A repository file named config/current is a symlink to /home/runner/.ssh/id_ed25519. The model asks to inspect a config file, and the tool returns a private key. The policy said repo-only. The filesystem followed a different path.

String prefix checks do not establish which object will be opened. .., symbolic links, mounts and races between checking and opening can move the actual target outside the allowed tree. Even calling realpath and then opening the original name leaves a check-to-use window if an untrusted actor can change the directory. Linux openat2 offers constrained path resolution, including RESOLVE_BENEATH and options for refusing symlinks, under specified kernel and filesystem conditions. The exact enforcement needs to be designed for the host OS and threat model, not assumed from this one call.

I would first remove secret mounts from the agent's execution environment. A tool with no legitimate access to the private key should not be one bug away from reading it. Then open relative to a trusted directory handle with enforced containment at the actual open operation. Choose whether in-repo symlinks are allowed, and if so still reject escapes. Treat bind mounts and hard links as a separate review of what is visible inside the sandbox. Keep credentials outside it, restrict network egress, and prevent the agent from bypassing read_file with an unrestricted shell or test runner. One scoped wrapper does not provide containment if another capability can read the same filesystem.

The interviewer may ask whether simply denying symlinks breaks real repositories. It can. Plenty of projects use symlinks. The policy can allow links whose resolved targets stay inside the workspace and deny external targets, or use a staged immutable workspace with only approved files. State the product choice and test it. Include a symlink swapped during access, ../, absolute links, nested links, a mount boundary and a normal in-repo link. Test the bytes returned, not just an allow/deny log.

If the key was actually returned, rotate it, audit use and investigate all reads through the tool. This is distinct from A coding agent runs repository tests that can read its secrets, where running repository tests may expose secrets. Here a nominally read-only file tool escapes its intended filesystem scope during path resolution.