If you tell one AI agent 'never spend over $500,' how do you make sure every agent it hands work to obeys?

This explores how one starting request can carry its limits down a chain of agents handing work to each other. The corpus has no paper that answers this end to end. It has several partial mechanisms and one clearly marked gap.

The closest mechanism is a task-bound signed token checked by a separately verified policy oracle. The idea is that the request's scope becomes an object that travels with the work, instead of instructions each agent re-reads and might be talked out of. One paper reports zero unsafe actions with this setup, but the excerpt never says who issues the tokens, what binds them, or whether attacks were positioned to reach the checker (How does the authorization layer stay outside the poisoned path?). Treat it as a promising shape, not a recipe. What the excerpt does make clear is that the checker has to sit outside the path an attacker can poison.

The corpus also says what the scope has to be made of. Per-action guardrails can't state rules that depend on history, so individually fine steps can add up to a violation. Catching that takes a stateful monitor that follows the whole chain (Can stateless checks ever catch sequence-level constraint violations?). Naming a prohibition isn't enough either: in one test, protected tests stayed untouched only when explicit boundaries came paired with restricted tools, and the boundary had to name the protected state itself (Can explicit authorization boundaries prevent agents from modifying protected tests?). Nobody has separated how much of that came from the rules and how much from the tools (Do authorization rules or restricted tools prevent test modifications?). The practical reading is that a scope should shrink what each downstream agent can do, not just tell it what to avoid. Another line of work embeds rules in the memory an agent actually consults while working, which is one way to make sure it sees them (Can governance rules embedded in runtime memory actually protect autonomous agents?).

The chain itself is also something attackers can go after, so the scope has to survive that. Agents can be tricked into passing work around in circles (Can agents be tricked into delegating work in circles?). The layer deciding which model handles a request can be manipulated, which can send work to a weaker model or make safety checks run against the wrong identity (Can attackers manipulate which model handles a request?). The corpus doesn't say this, but it suggests that a scope which travels with the request would be the natural place to record lineage and bind itself to the verified identity of each handler.

Two questions remain open. The first is who gets to write the invariants once the chain leaves the originating organization. The operator, the organization, the regulator and the standards body each have their own rules, which may conflict and may not be visible to every party, and the paper that raises this never names an owner (Who enforces invariants when agents cross organizational boundaries?). The second is how tight the scope should be. Delegation research suggests it should depend on the task, since criticality, reversibility and verifiability all shape how much freedom a delegate should get (What makes delegation work beyond just splitting tasks?). Once a scope exists, cryptographic commitments could let each hop prove it stayed inside it without exposing the underlying content (Can commitments protect sensitive agent data while enabling verification?).