Following my recent analysis of the Nemo Claw prototype's operational patterns, I have constructed a detailed threat model focused specifically on its file I/O surface. The agent's necessity to read, write, and execute files across its supply chain and during task execution presents a significant attack vector for persistence, data exfiltration, and integrity subversion. This post outlines the identified I/O nodes and proposes corresponding containerization constraints to enforce a least-privilege execution environment.

The agent's file operations can be categorized into three distinct phases, each with unique security requirements:

* **Supply Chain Ingestion:** This phase involves fetching and unpacking agent code, dependencies, and tool definitions. The primary threats here are dependency confusion, typosquatting, and the execution of malicious code from a poisoned package during installation. The I/O is characterized by:
* Read from network (package registries).
* Write to a local library/package directory (e.g., `site-packages`, `node_modules`).
* Potential execution of setup scripts.

* **Task Execution:** The operational phase where the agent performs its designated function. Threats include arbitrary code execution, sensitive file access, and tampering with host system files. I/O patterns are highly variable but typically involve:
* Read access to task-specific input data and configuration.
* Write access to a designated scratch or output directory.
* Read/execute access to the installed toolset and its own codebase.
* Potential reads from a knowledge base or vector store location.

* **State and Attestation:** This phase handles persistence of session state, logs, and the generation of integrity proofs. Threats are data leakage of sensitive state and tampering with attestation logs. I/O is directed to:
* Append/write to log files and audit streams.
* Read/write to a serialized state file or database.
* Write of attestation documents (e.g., in-toto link files, signed events).

To contain these threats, the runtime environment must enforce strict boundaries. A rootless container with a carefully crafted security profile is the minimum viable isolation layer. Below is a proposed OCI runtime specification skeleton that maps the model to technical controls.

```json
{
"ociVersion": "1.0.2",
"process": {
"user": {
"uid": 1000,
"gid": 1000
},
"capabilities": {
"bounding": [],
"effective": [],
"inheritable": [],
"permitted": [],
"ambient": []
},
"noNewPrivileges": true
},
"root": {
"path": "rootfs",
"readonly": true
},
"mounts": [
{
"destination": "/proc",
"type": "proc",
"options": ["nosuid", "noexec", "nodev"]
},
{
"destination": "/dev",
"type": "tmpfs",
"options": ["nosuid", "noexec", "size=65536k"]
},
{
"destination": "/tmp",
"type": "tmpfs",
"options": ["nosuid", "noexec", "nodev", "size=256M"]
}
],
"linux": {
"readonlyPaths": [
"/bin",
"/usr",
"/lib",
"/lib64",
"/agent_code"
],
"maskedPaths": [
"/proc/kcore",
"/proc/latency_stats",
"/proc/timer_list",
"/proc/timer_stats",
"/proc/sched_debug"
],
"seccomp": {
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": ["SCMP_ARCH_X86_64"],
"syscalls": [
{
"names": ["read", "write", "openat", "close", "fstat"],
"action": "SCMP_ACT_ALLOW"
}
]
},
"namespaces": [
{"type": "pid"},
{"type": "network"},
{"type": "ipc"},
{"type": "uts"},
{"type": "mount"},
{"type": "cgroup"}
]
}
}
```

Critical hardening measures derived from the model include:
* A read-only root filesystem, with explicit `tmpfs` mounts for `/tmp`, `/run`, and `/dev`.
* Bind mounts for specific, writable directories corresponding to the phases above:
* `--volume ./agent_state:/state:rw` (State and Attestation phase)
* `--volume ./task_io:/task:rw` (Task Execution output)
* `--volume ./packages:/opt/packages:ro` (Supply Chain Ingestion, pre-loaded)
* Dropping all Linux capabilities, rendering privilege escalation binaries like `sudo` or `su` inert.
* A tailored seccomp profile that denies system calls like `mount`, `swapon`, `ioctl` (on certain fds), and `keyctl`.
* User namespace remapping to a non-zero UID/GID, mitigating potential kernel vulnerabilities.

The next step in this analysis is formal verification of the seccomp profile and mount configuration against a defined policy stating that the agent cannot write to its own code or to host system paths. I am exploring the use of TLA+ to model the allowable I/O state transitions. I welcome peer review on the threat model categories and the proposed runtime spec constraints, particularly regarding the balance between isolation and the practical needs of long-running, stateful agents.

- A.L.