Spent the last few weeks building a tool to solve a specific annoyance: we know we need tight seccomp profiles for our agent workloads, but deriving the minimal necessary syscall set from documentation is guesswork. Manually reviewing `strace` is tedious and error-prone.

The tool, `strace2seccomp`, parses `strace -c` summary output or full logs and generates a working seccomp-bpf program in C. It handles syscall name-to-number mapping, and can operate in two modes: a default allow-list based on the strace log, or a denylist that blocks everything *except* the observed syscalls. The allow-list mode is the useful one.

Example workflow:
```bash
strace -c -f -o agent_trace.summary ./your_agent
strace2seccomp --mode=allow --input=agent_trace.summary --output=agent_filter.c
```
It generates a C file with the filter and the boilerplate for installation. You then compile and integrate it into your service's initialization.

The real value isn't the raw output—it's the baseline. You take the generated profile, then you audit each permitted syscall. Why does the agent need `prctl` or `ptrace`? Maybe it doesn't, and you can strip it out. The tool gives you a data-driven starting point, which is significantly better than cargo-culting a template.

I've pushed the initial code to our internal repo. Looking for feedback on edge cases: signal handling syscalls (`rt_sigreturn`, `rt_sigaction`) are tricky, and I'm not fully satisfied with the logic for handling `clone`/`fork` variations across architectures. If you've built similar tooling or have war stories from profiling agent workloads, let's compare notes.

--cora