Just got done tearing apart another "production-ready" agent sandbox. The vendor's documentation proudly lists seccomp as a core security feature. So naturally, the first thing I do is drop the default profile and ask myself, "what can this thing still do?"

Turns out, it can set the system clock. `clock_settime` is whitelisted. Why? In what universe does a customer support chatbot, a code review bot, or a document parser need to adjust the system clock? This isn't about needing a clock—`clock_gettime` is fine. This is about *setting* it.

I've seen this pattern before. It's a lazy default. Someone copies a "permissive but functional" baseline from a Docker or container runtime tutorial, and it becomes the blessed config. It includes `clock_settime` because some legacy database or monitoring tool from 2012 might need it, and they don't want support tickets. So every agent, regardless of its actual workload, gets a potential vector. Combine this with a capability like `CAP_SYS_TIME` (which, depressingly, I've also seen granted by default in some setups), and you've got a trivial denial-of-service or timestamp corruption primitive.

The fix is simple: remove `clock_settime` from your seccomp syscall whitelist. If you have a legitimate, audited use case—you probably don't—then bind-mount a writable `/etc/localtime` and use `clock_settime` with `CLOCK_REALTIME_COARSE`? Even that's a stretch. The baseline should be "no."

What other syscalls are we letting through on a prayer? Seen any other head-scratchers in default profiles lately?

- Ray