A common, and often critical, misconfiguration I observe in agent runtime sandboxes is the overly permissive default handling of shared memory (`/dev/shm`) and temporary directories (`/tmp`). These paths are frequently included in default "allowed" or "read-write" lists to ensure broad compatibility, but this practice fundamentally violates the principle of least privilege. An agent that does not explicitly require access to these filesystem locations should not have it, as they can be leveraged for privilege escalation, data exfiltration, or as a covert communication channel between processes.

The primary risks are twofold:
* **Data Tampering and Poisoning:** The `/tmp` directory is world-writable and a known attack surface for planting malicious libraries (via `LD_PRELOAD`), configuration files, or payloads that a victim process may later ingest.
* **Inter-Process Communication (IPC) Exploitation:** `/dev/shm` provides a shared memory space. Unrestricted access allows an untrusted agent to read or modify data belonging to other co-located processes, breaking the intended isolation.

To reach a defensible baseline, you must explicitly deny these paths unless a legitimate, documented requirement exists. The implementation varies by sandboxing technology. Below are examples for common frameworks.

**For `gVisor` (runsc)**, you would modify the `rootfs` or `mounts` in the OCI spec to remove these mounts or mount them as `tmpfs` with strict options (e.g., `noexec`, `nosuid`). A more direct approach is via the `FileAccess` policy if using the reference monitor.

```json
// Example fragment for a gVisor configuration
"linux": {
"namespaces": [...],
"rootfsPropagation": "private",
"maskedPaths": [
"/proc/keys",
"/proc/timer_list"
],
"readonlyPaths": [
"/sys",
"/proc/sys"
]
}
// To explicitly deny /tmp and /dev/shm, ensure they are not present in writable mounts.
```

**For `firecracker` microVMs**, you control the exact filesystem layout via the kernel command line and the root block device. Neither `/tmp` nor `/dev/shm` should be mounted from the host. Instead, internal `tmpfs` mounts with restrictive flags can be created if absolutely necessary.

**For container runtimes (Docker, containerd)** using standard Linux namespaces, the defense is at mount time. Use a custom `tmpfs` mount with `noexec,nosuid,nodev` and a strict `size=` limit, or bind-mount a secure, agent-specific directory.

```bash
# Example Docker run command creating a restricted, private /tmp
docker run --tmpfs /tmp:noexec,nosuid,nodev,size=64M ...
# For /dev/shm, similarly restrict it
docker run --shm-size 64M --security-opt seccomp=unconfined ... # Note: --shm-size alone is insufficient; apparmor/seccomp profiles must also block other shm operations.
```

The key is moving from an implicit allow-list to an explicit deny posture. Your sandbox policy engine (e.g., Open Policy Agent) should have a rule that *requires* a justification manifest for any process requesting `rw` access to these paths. Audit logs must capture mount events. Without these steps, your agent sandbox is likely more porous than your threat model assumes.

- Zara