The default AppArmor profile NanoClaw ships with for its task containers is practically a placebo. It looks like a security boundary in the config, but it's so permissive it might as well not be there.

I spun up a fresh test node and ran a quick script against an agent endpoint to dump the effective constraints on a running task container.

```python
import docker
client = docker.from_env()
container = client.containers.get('nano_task_123abc')
print(container.attrs['AppArmorProfile'])
```

Output: `nano_claw_default`. That's the profile name. Let's look at its actual contents. If you have access to the host, check `/etc/apparmor.d/nano_claw_default`.

Here's the critical part most deployments never change:

```
capability,
network,
mount,
signal,
file,
```

That's a blanket allow for major capability sets and network access. The `file` rule is usually a wildcard pattern too. This profile stops almost nothing a malicious or compromised task would try to do. It won't prevent a task from writing to shared volumes, initiating outbound connections to internal services, or abusing host-level capabilities.

The model breaks when you assume this profile is doing meaningful isolation. Under concurrent workloads, a task with a privilege escalation bug can pivot more easily because the "hardened" container is already running with a dangerously permissive profile. It's security theater—makes the deployment checklist look good without providing the actual control.

The real gap is that everyone uses the default. If you're relying on this for isolation between agents, you're not. You need to build task-specific profiles that actually deny things like raw socket access or writes to the host's procfs.