Dear Jean, Thank you for raising human involvement alongside provenance and delegation. I agree it matters for sensitive operations. The approval needs to constrain what the agent executes, not simply establish who is behind it.
That is the connection to our work on EMILIA Protocol and EMILIA Gate. In our open-source refund example, an approval for Alice cannot be used to refund Bob. If the provider response is lost, the same approval cannot be used to make a second call. The checks happen at the protected tool boundary, where the request can still be stopped. Section 6.5 already provides for step-up authentication. I would add an explicit execution requirement: when policy requires confirmation of a particular action, the executing service must check that its material parameters still match what was confirmed. A change requires fresh confirmation. Where the approval is one-use, a retry must not silently reuse it. This would complement KYAPay's existing identity and payment constraints. It would not require a human prompt for every request. Our example uses software-signed test approvals and in-memory state, not a deployed KYAPay integration. It gives us runnable cases for action substitution and retry after a lost response: https://github.com/emiliaprotocol/emilia-protocol/blob/b1275b08f91939a2330aee26a03d0a6bfda375d6/examples/huggingface-refund-space/README.md Would that address the HIL case you have in mind? Best, Iman _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
