Separate explanation, preparation, and execution
Explaining a transaction, preparing one for review, and executing future operations are different tasks. Give each task a defined completion point. A document comparison should be able to finish as a comparison without requesting a wallet signature.
OWASP's Excessive Agency guidance recommends enforcing authorization outside the model's own judgment. Applied here, a useful architecture lets the assistant assemble evidence while a separate policy layer evaluates whether a proposed operation fits the user's scope. Document who can change that scope and how the change becomes visible.
Make the recommendation inspectable
Ask for an evidence packet containing the source, observation time, relevant uncertainty, interpretation, and proposed action. Preserve the difference between what a report states and what the assistant concludes from it. This lets a reviewer challenge an inference without losing the original observation.
A hypothetical transfer proposal should identify the account, network, token, destination, and amount. If the destination changes after review, the earlier approval no longer describes the same operation. The AI approval safety guide develops this relationship between the evidence packet and the exact transaction.
Design an explicit stop and recovery path
Rejection should end the proposed action cleanly. Expiration should produce a revised proposal, with changed terms made visible. When submission status is uncertain, investigate the existing operation before generating a replacement that could repeat its effect.
For a design review, try an outdated input, a changed network, a replaced recipient, and a refused approval. Identify which component handles each case and what the person sees. Continue with decision API workflows when you need a structured format for proposals, status, and recorded approvals.
