A spawned sub-agent inherits the parent's bypass settings unless you scope it explicitly

The failure starts at spawn. You configure an orchestrator with a narrow tool list and approval gates, it decomposes the goal, and it creates a child agent for one piece of the work. According to the dev.to post, that child can silently inherit the parent's permissions and bypass settings unless you scope it explicitly, arriving with full tool access and no approval gates ^[8]. "Nobody granted it that on purpose. The default did," the post says ^[9]. It refers to the LoopRails codex for the scoping guidance and does not name a particular runtime or setting, so the check is on your own spawn call and what a child gets when you pass nothing ^[19].

The grading rule is what forces the design. Each tool action is scored on reversibility, blast radius and stakes, G0 to G3, and the instruction is to grade the action regardless of which agent or sub-agent takes it ^[14]. A grade that belongs to the action has to be enforced where actions happen, which is the client library or broker the calls pass through. Provenance ends up in the same place, because five agents sharing one set of credentials produce logs that say "the system did X" and cannot say which one acted ^[10].

Three of the four prevention requirements are pre-call checks, so one component in the call path can carry all of them ^[18]. The cap is the expensive one. The post's example is ten sub-agents each making small external calls, spending a little and touching a few records, which adds up to a system-level effect that no per-action grade captures ^[11]. A per-action check sees one call. Seeing the total means a counter every agent decrements before it acts, and those agents run concurrently and pass results back to the orchestrator ^[7].

The kill switch has the same shape. "If you can only stop them one at a time, the rest keep running while you scramble, which is not a stop at all," the post says ^[13]. A flag the broker reads before each call meets that bar for every call that goes through the broker. In the reference architecture described, one sub-agent writes code and another calls external APIs ^[7]. Give the code writer a shell and the gate, the counter and the switch all have a path around them.

This is a design argument, and the post presents no incident and no measurement. It rests on one question from the LoopRails framework, whether a human can realistically catch the mistake in time, and answers almost always no for a swarm ^[6]. Underneath it the author puts the principal-agent problem: stack more delegates and the action drifts further from the human meant to own it ^[15]. I think the four moves are right in a system where every tool call already passes through one client you own. Where they do not, that client is the first thing to build, and the controls are configuration on top of it ^[5].