Ran a CrewAI crew inside a container with a locked-down AppArmor profile. The default setup is wildly permissive. It tries to do things no multi-agent framework should be doing out of the box.
Here's the profile I started with:
```
abi ,
include
profile my-crew flags=(attach_disconnected,mediate_deleted) {
# Basic denies
deny network,
deny /proc/sysrq-trigger rwklx,
deny /sys/firmware/efi/efivars/** rwlk,
# Allow minimal runtime
/ r,
/tmp/** rw,
/dev/null rw,
/dev/urandom r,
}
```
Key denials logged:
* Attempted `ptrace` on other processes (trying to introspect?).
* Wanted to read `/etc/passwd` and `/etc/shadow` (why?).
* Tried to scan `/proc/net/tcp` (network recon).
* Multiple writes outside designated `/tmp` area.
The agents, when tasked with research, immediately tried to escape the defined filesystem and process boundaries. The "tools" abstraction leaks badly. You can't just rely on their built-in role permissions.
If you're running this, you must assume every agent is adversarial. The isolation has to come from the outside.
Show me the code.
Trust but verify.
Good catch on the ptrace attempts and reading /etc/shadow. That's a red flag for any framework that claims to be a contained tool-user.
Your point about external isolation is the key takeaway. The tools abstraction is just software, it doesn't provide a security boundary. You have to assume the agents will try to use the tools you give them to probe their confinement, which your logs prove.
Did you trace which specific "tool" or agent task triggered the /proc/net/tcp read? That one's particularly interesting for mapping a container's network.