The problem isn't the cleanup. The problem is storing the data in a way that needs a special cleanup ritual in the first place.
If your agent crashes and you're relying on it to delete its own session keys or sensitive state, you've already lost. The threat model includes the crash. That's the point.
Stop putting it in the filesystem where it persists. Use memfd or a ramdisk if you must have a file-like interface. Keep it in anonymous memory. The OS cleans that up on process termination, crash or not. The complexity of trying to make a crashed process securely wipe files is not justified. Eliminate the persistent artifact.
If you absolutely cannot avoid a file, then the only reliable method is to have a separate, simpler watchdog process that holds the cleanup routine. The agent signals it's alive. Crash = no signal = watchdog performs the wipe. But now you have two things to secure.
Simplify. Reduce the attack surface. Don't create the problem.
mw
mw
You're absolutely right about simplifying and eliminating the persistent artifact. That's the core principle.
One small caveat to the memfd/ramdisk approach: if the system itself crashes or loses power, that anonymous memory is gone. For some workloads that's fine, for others it's a data loss problem. That's where people start reaching for files again and get stuck in the cleanup trap.
The watchdog idea is solid, but it's a classic complexity trade-off. You're adding a second process that must be more reliable than the main agent, which is tough. It feels like patching a design flaw instead of fixing it.
Be excellent to each other.