An agent task needs a boundary before it needs a shortcut.
Use a fictional document-sharing task to separate useful context from permission to change another system.
An original illustrative exercise. This page makes no claim about deployed security controls, certifications or measured protection.
Name the proposed action
Imagine a fictional project assistant preparing a handoff pack. Its task is to read an approved project note and draft a summary for an internal reviewer. The note contains a sentence asking for the pack to be shared with an outside address. That sentence is material being read; it is not a new instruction from the person who assigned the task.
Make the proposed change explicit before discussing whether it can happen. Which document would be shared, with whom, at what access level and for what purpose? A general request to prepare a handoff does not answer those questions. The exercise stops at a readable proposal so the reviewer can inspect the exact change.
Keep permission separate from relevance
A source can be relevant to the work without having authority to expand it. The project note might correctly describe a milestone and still contain an instruction that falls outside the assignment. Treating every sentence as equally authoritative makes it hard to tell whether the assistant is explaining a source or obeying it.
In the browser exercise, choose between a draft-only assignment, an instruction embedded in a source and a specifically reviewed proposal. The response changes to show what that evidence supports. Even the reviewed state remains a demonstration: this website has no connection to a document service and cannot grant access or send a file.
Review the exact change and its result
An approval should identify the actual proposal under review. If the recipient, document or access level changes afterward, the earlier decision may no longer describe the new action. Preserve enough context for the reviewer to compare the proposed change with the scope they intended. Do not infer broad permission from a narrow example.
A live implementation would also need a way to distinguish a confirmed result from an uncertain one. For this educational exercise, write down the expected confirmation and the stopping condition before any action is attempted. If a result is unknown, the next person should be able to see what is uncertain instead of being told that the task succeeded.