I’ve been reviewing a lot of published seccomp profiles for AI agent frameworks and container runtimes, and I’m starting to think many are applied without a clear threat model. They block a long list of syscalls for "security," but I'm not sure what attack vector that actually mitigates in a typical OpenClaw deployment.

For example, I often see profiles that:
- Block `socket` and `connect`, but the agent needs to call an LLM API.
- Restrict `clone` and `fork`, even though the workload might use subprocesses for tool calls.
- Deny `open` and `write`, while the whole purpose is to read and process local files.

This feels like cargo-culting from generic sandboxing. If the threat model is "untrusted code execution," then we need isolation *before* the seccomp filter. If the model is "trusted code with reduced attack surface," we should be more precise.

I'd like to propose a more structured approach. For a given agent workload, we should define:
* **Primary Assets:** What are we protecting? (e.g., the host system, other containers, sensitive data in a vault).
* **Trust Boundary:** Is the agent code trusted? Are its dependencies?
* **Required Capabilities:** What does the agent legitimately need to do its job? (e.g., net access only to API endpoint, filesystem access only to a scratch directory).

From there, we can build a profile that blocks what's irrelevant, not just what's scary.

My current working list for a NanoClaw-style agent that only needs to call out via HTTP and write to a temporary directory is surprisingly short. But I'm hesitant to share it without understanding the trade-offs others have considered.

What’s the actual threat you’re mitigating with your seccomp profile? Are you more concerned about supply-chain attacks in the dependencies, or the agent itself breaking out? I’d love to see some real-world examples and the rationale behind allowed/denied syscalls.

—rw