I'm setting up a multi-agent system for a customer support pipeline. All agents live in the same environment and can access a shared workspace for documents and task status.
I'm trying to do a threat model for this, but the templates I find mostly focus on external users attacking the system. My worry is internal: what can a compromised or malicious agent do to the other agents?
* Can one agent poison the data another agent uses?
* Could a prompt injection against Agent A make it attack Agent B's process?
* How do you even draw the trust boundaries in a data-flow diagram for this?
I'm specifically thinking about shell_injection risks and how an agent with tool access could escalate. Are there example STRIDE diagrams for inter-agent threats?
You're right to focus on internal threats. Treat each agent as an untrusted, potentially hostile principal. Your shared workspace is the biggest risk surface.
For your STRIDE: map each agent's tool permissions as trust boundaries. If Agent A can write to a file Agent B reads, that's spoofing/tampering/repudiation. If an agent can execute shell commands, it can directly target other processes if isolation is weak.
Draw your data-flow with each agent in its own box, all connecting to the "shared workspace" which you label as "high-risk trust zone". Then model attacks along those data flows.
For shell injection, don't just sanitize inputs. Run each agent under a separate Linux user ID, use seccomp to block process manipulation syscalls, and AppArmor to restrict file writes to only designated directories. This limits lateral movement.
Drop the --privileged flag.
Separate user IDs don't mean much if they all share a common group for that workspace. The real trick is using a separate mount namespace for each agent, with the workspace bind-mounted read-only where possible. AppArmor profiles are good, but you have to write them correctly - most people just use complain mode and call it a day.
> use seccomp to block process manipulation syscalls
This is key, but you need to audit which syscalls your runtime actually uses. A blanket deny on `ptrace` and `process_vm_readv` is a start. Also consider `prctl` to disable subreaper flags.
Totally agree on the mount namespace trick, that's saved me a few times. I use the `--read-only` bind mount for shared config, then a separate, tiny `tmpfs` mount for the agent's own scratch space. Stops any cross-contamination cold.
One caveat on the seccomp audit: if you're containerizing each agent (which you should be!), remember the container runtime itself might need a syscall. I once broke a Docker setup by blocking `setns` across the board. A quick `strace -f` on the agent's entry point is your best friend here.
And yeah, complain mode is just a fancy log generator. I finally bit the bullet and wrote a real AppArmor profile after a misbehaving test agent tried to write to `/proc`.
self-hosted, self-suffering