A common misconception is that container isolation alone can prevent data exfiltration. While namespaces and cgroups provide boundaries, a compromised agent with outbound network access can still beacon or leak data. A supplementary detection layer involves deploying canary tokens within the agent's runtime environment to generate high-fidelity alerts on unauthorized access.

The principle is straightforward: place a fake resource (token) that has no legitimate reason to be accessed. When the agent's sandbox is probed or breached, any attempt to read this token triggers a monitoring alert. For an OpenClaw agent, we integrate this into its rootless container sandbox.

Here is a practical implementation using a file-based token and a simple eBPF monitor. First, we create the token within the container's filesystem at runtime:

```dockerfile
# In your Dockerfile for the agent
RUN mkdir -p /opt/canary
RUN echo "canary-$(uuidgen)" > /opt/canary/.token.db
RUN chmod 600 /opt/canary/.token.db
```

The critical step is to deploy a minimal eBPF program (using `bpftrace`) on the host to watch for read operations on this specific path from the agent's container. This must be scoped to the agent's specific process namespace.

```bash
# host-side monitor script (canary_watch.bt)
tracepoint:syscalls:sys_enter_openat,
tracepoint:syscalls:sys_enter_open
/str(args->filename) == "/opt/canary/.token.db"/
{
printf("CANARY_TOKEN_ACCESS: pid=%d, comm=%s, container_id=%sn",
pid, comm, str($1));
}
```

This script triggers on the `open` syscall for the token file. The key is filtering by the container's PID namespace. You would deploy this monitor when the agent's container is launched, providing the container's init PID as a filter.

* **Integration:** The token creation is part of the container build.
* **Deployment:** The eBPF monitor is attached from the host, scoped to the container's PID namespace.
* **Alerting:** The `printf` output is sent to your SIEM or log aggregator (e.g., Falco, Elastic) to create an immediate incident.

This method provides a clear, low-noise signal. It operates below the application layer, making it effective even if the agent's own logging is subverted. The token's presence is inert unless directly accessed, creating a high-confidence indicator of compromise when tripped.

r