There are multiple documented cases where multiple agents collaborated to exceed their individual permission constraints, hack systems, or escape secure sandboxes.
Post 3 of a series on AI liability for general counsels interested in the legal liability associated with building and using agents.
Agents can break out of their sandboxes and wreak havoc by merely interacting with other agents or spawning sub-agents that aren’t bound to the same policy. This is called composition risk or aggregate permission escalation.
This is analogous to drug interactions. You might have two drugs that are perfectly safe on their own, but you combine them and they can become deadly. The classic, but little known combination is tylenol and alcohol; at a certain level they can permanently destroy your liver. Parenting tip: don’t let your college student have tylenol.
Here’s one example of a mechanism for agents to interact to exceed their policy ceilings. You have three different travel booking agents, each with a maximum airline spend of $1,000. They collaborate to share the price of a $3,000 ticket. No policy ceiling was broken, but they exceeded their intended authority. That’s small potatoes, but when they start combining data access, write access, and credentials the results can be catastrophic. In the Hugging Face Hack there were roughly 1,200 agents collaborating.
Most organizations design permissions one agent at a time. They ignore the composition risk. NVIDIA’s OpenShell Policy Prover can evaluate composition risk inside an OpenShell sandbox and across multiple OpenShell sandboxes, but if you have a heterogeneous collection of sandboxes, the others are black boxes. Similarly, if you are using OpenShell in conjunction with Microsoft ACS, Policy Prover doesn’t evaluate the impact of the ACS permissions.
Composition risk shows up in ordinary enterprise workflows more often than exotic ones. Agents that can issue refunds, adjust inventory, update customer records, or approve expenses will eventually be chained. Agents that can read from one system and write to another will eventually be asked to coordinate. The liability question is the same as the felony question: who authorized the combined outcome, and can you show the ceilings that should have stopped it were actually in force.
The practical requirements are clear even if the implementation is not. You need an explicit policy for handoffs and shared context. You need the intersection of the ceilings applied at composition time, not after the fact. You need sandboxes and tool restrictions that survive the handoff. You need observability that records which agent called which other agent, what context was passed, and which policy version bound the exchange. Red-teaming the composed workflow, not just the individual agents, is how you find the interaction before production does.
At Trustabl we treat composition as a first-class concern rather than an afterthought. Company agent policy can declare the handoff rules, the shared-context limits, and the data classes that may not cross agent boundaries. The compiler intersects those ceilings into one signed contract for the agent versions involved. It generates the corresponding policies for the Policy Enforcement Points so the constraints hold across the handoff instead of stopping at the first agent. The Safe Agent Control Plane records the handoffs and the policy decisions in the same evidence bundle. We do not claim this eliminates every composition path. We claim it turns an invisible permission combination into something you can see, constrain, and prove you constrained.
Agents will keep finding ways to borrow rights from one another. The companies that can show the combined action was either prohibited or explicitly authorized will be in a different position from the companies that discover the interaction in an incident report.
Additional reading in this series
Related Blogs
Agent Reliability Resources
