I have been analyzing the behavior of several AI coding agents, including Cursor's agent mode, and a common pattern emerges: heavy reliance on temporary directories like `/tmp` for writing intermediate files, scripts, and even downloaded dependencies during its operation. This presents a clear and present security risk, especially when the agent is granted broad system access to perform its tasks.

The primary concerns are:
* **Data Leakage:** Sensitive project code or environment variables could be written to world-readable temporary files.
* **Persistence Attack Vector:** An attacker who gains any form of code execution within the agent's context could plant scripts or payloads in `/tmp` to be executed later.
* **Lack of Audit Trail:** Files in `/tmp` are ephemeral and not designed for secure logging or forensics.

My immediate thought was to employ a mandatory access control framework like AppArmor or SELinux to create a strict profile. However, crafting and maintaining these profiles for a rapidly evolving tool like an AI agent can be cumbersome.

This leads to my question regarding **NanoClaw**. From its documentation, it appears to be a lightweight sandboxing tool, potentially using namespaces and seccomp-bpf. Would it be suitable for this specific use case?

My ideal configuration would:
* Restrict the agent process to a private, isolated `/tmp` directory.
* Block network access to everything except a defined set of package repositories (e.g., specific PyPI or npm registries).
* Enforce a read-only bind mount for the majority of the host filesystem, with read-write access only to the specific project directory.

A conceptual NanoClaw profile might look like this:
```yaml
profile: cursor-agent
executable: /usr/bin/cursor
unshare:
- ipc
- pid
- net
- uts
- user
- cgroup
mounts:
- type: tmpfs
target: /tmp
data: "size=256M,nr_inodes=64k,mode=1777"
- type: bind
source: /home/user/project
target: /project
readonly: false
- type: bind
source: /usr
target: /usr
readonly: true
seccomp:
action: log
arch:
- x86_64
syscalls:
- accept
- bind
- socket
```

Has anyone attempted a similar sandboxing strategy for AI coding agents? Specifically, I am interested in:
1. The practical effectiveness of NanoClaw versus more traditional MAC frameworks in this context.
2. Any pitfalls in restricting network access without breaking the agent's core functionality for fetching context or dependencies.
3. Methods for securely handling the agent's need to execute the code it generates within the same sandbox.