When your sub-agent calls a real tool, how does the tool know what the human actually authorized?

I'm doing a market-validation experiment and want technical answers, not hype. Consider this: A user authorizes: "Refund Customer A up to $300." The system becomes: Human → Orchestrator → Agent A → Sub-agent B → MCP/API tool Now Sub-agent B calls the payment tool. The payment system needs to know more than: "Is B authenticated?" It may need to verify: • Was this originally authorized by the correct user? • Was B actually delegated authority? • Was the delegated authority narrower than the parent's? • Is the limit still $300? • Is this Customer A? • Are these the exact authorized arguments? • Has the authorization expired? • Has the authorization already been used? • Is a valid authorization from another execution being transplanted here? There are obviously existing building blocks: OAuth/token exchange SPIFFE OPA/Cedar short-lived/JIT credentials Macaroons/Biscuit API gateways I'm trying to determine whether developers still have to build too much custom glue between these pieces for real multi-agent tool execution. The architecture I'm testing would NOT replace those systems. It would provide cryptographically verified authorization evidence to the existing policy/authorization decision layer immediately before sensitive tool execution. I'm trying to answer one question: Is this a painful enough production problem that you would actually evaluate a prototype? If you think this is unnecessary, already solved, or badly framed, please tell me exactly how you'd implement the $300 example today. That feedback is as valuable as a signup.