This is a common deflection tactic, particularly from vendors whose security architecture lacks depth or formal rigor. The statement "nobody else asks for this" is almost always an indicator that their security model is either immature, built on assumed trust rather than verified isolation, or deliberately opaque. In the context of agent runtime security—where we are deploying code with elevated privileges, often across multi-tenant environments—this response is unacceptable. It signals a fundamental misalignment between their product's posture and the principle of least privilege.

When evaluating an agent vendor, you must move beyond marketing claims of "secure by design" and demand technical specifics. The areas where this deflection most frequently arises are in the details of process isolation and system call filtering. A vendor might claim their agent is "containerized" or "sandboxed," but resist providing the exact mechanisms. Your questionnaire must force concrete answers. For example:

* **Namespace Isolation:** Which specific Linux namespaces are utilized? Is it a full `unshare(CLONE_NEWUSER | CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | CLONE_NEWNET)` call, or a partial set? Is the user namespace mapped, and if so, how are capabilities within it managed?
* **Seccomp-BPF Filters:** Is a restrictive seccomp policy applied? Request the actual filter source or a comprehensive list of permitted syscalls. A response of "we use seccomp" is meaningless without the filter rules. The difference between allowing `openat` and `open_by_handle_at` is substantial from a security perspective.
* **Capabilities Management:** Which Linux capabilities (e.g., `CAP_SYS_ADMIN`, `CAP_NET_RAW`, `CAP_DAC_OVERRIDE`) are retained by the agent process after initialization? A proper design should drop all capabilities not explicitly required for the agent's narrowly defined function.
* **Landlock Integration:** For newer kernels, is Landlock ABI used to create filesystem restrictions? This is a more granular control than simple namespace mounts.

If met with resistance, reframe the question in terms of breach containment. Ask: "If your agent process is compromised via a memory corruption vulnerability, what specific kernel-enforced boundaries prevent the attacker from accessing the host's process table, user sessions, or container orchestration daemon socket?" The answer should not be "our code is secure," but rather a description of the mandatory access control layers (e.g., seccomp, namespaces, AppArmor/ SELinux profiles) that would contain the blast radius.

Here is a minimal example of the kind of technical detail you should expect, presented in a format that permits audit. A vendor providing this demonstrates a mature, enforceable model.

```c
// Example excerpt of a seccomp filter for a monitoring agent
// Illustrates explicit allow-listing, not just denial of 'dangerous' calls.
struct sock_filter filter[] = {
BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, arch))),
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, AUDIT_ARCH_X86_64, 1, 0),
BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL_PROCESS),
BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, nr))),
// Explicitly allowed syscalls for core functionality
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_read, 8, 0),
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_write, 7, 0),
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_fstat, 6, 0),
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_sched_yield, 5, 0),
// ... more allowed calls ...
// Default deny: log and trap unknown syscalls for analysis
BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_TRAP),
};
```

The ultimate counter to "nobody else asks for this" is to establish that your organization's threat model requires verifiable isolation, not promises. If a vendor cannot or will not provide these details, they are introducing an unquantifiable risk into your environment. Your questionnaire is a litmus test for engineering rigor; treat their answer as the result.

- Jane