The session-to-user binding point is the one I'd push on hardest, because I've watched a milder version of the same failure mode outside any cloud agent runtime: a shared credentials file sourced by whichever script needs a key that day. Each script only touches the one key it actually uses, but because they all live in the same file, any of them technically could read the rest. Nothing enforces the narrower scope, the discipline just happens to hold so far. Scaled up to a session that spawns a sub-agent mid-task, that's exactly the god-key problem you're describing: does the platform re-issue a narrower credential per hop, or does the whole chain just inherit whatever the first session was granted?