Keep permission attached to the intended action

An assistant is authorized to update a working copy of a document. While it prepares the change, the user opens another file in the same editor. If the assistant resumes by sending keystrokes to the foreground window, it may modify a document the user never intended it to touch.

Permission needs a target that the executor can check. A broad statement that a task is approved cannot resolve a changed window, a different destination, or an edited payload. The runtime must preserve what was authorized and compare it with the action it is about to perform.

The specification for Boris, a native agent interface, places authorization inside its task contract and desktop action loop. It calls for resource scope, recorded approvals, fresh target observations, and pauses on user takeover. Those are specified controls. The recovered source does not establish that all of them were implemented and passed an end-to-end demonstration.

An illustrative edit with a changed target

Suppose the user approves correcting a heading in a named working copy. Record the intended path, base revision, requested change, and allowed operation. The executor inspects the editor and confirms that the open document corresponds to that target before applying the edit.

Now introduce a user interruption. The user switches the editor to a second document, makes a change, and leaves it open. On resume, the assistant should obtain a fresh observation and compare the target identity with the approved operation before sending input, since reusing the old screen coordinates could apply a permitted correction to a document that was never included in the user’s approval.

If the original file remains available and unchanged, the workflow can return to that file and continue within scope. If its content has changed, inspect the difference before applying the pending patch. A new paragraph inserted above the heading may be compatible with the requested correction; a rewritten heading may require clarification because the approved edit no longer describes the current content.

The example is illustrative. Its acceptance criterion is observable: only the authorized working copy receives the intended correction, and the unrelated document retains the user’s intervening edit. The record should identify the observation used to revalidate the target.

Separate access from authority

A tool may be able to read or write many resources. That capability does not establish permission to use all of them for the current task. Give the execution layer a bounded resource scope and check the resolved target before a mutation, including aliases or links that could redirect the operation outside the permitted location even when the path originally supplied appears to belong to the approved workspace.

The same distinction applies to external destinations. Permission to prepare a report does not automatically include permission to upload it to a service or send it to another person. Store the approved effect with its destination so that a later convenience step cannot silently broaden the task.

Keep approval records versioned. If the user changes the destination, payload, or consequential terms, preserve the amendment and reassess which earlier approval still applies. A summary saying “user approved” is too coarse when it omits the thing approved and the conditions that made the decision meaningful.

Handle a pause without discarding the task

A permission boundary need not erase useful progress. Save the prepared artifact, current contract version, and exact pending action. Continue independent authorized work if the task contains any. When approval arrives, compare it with the pending operation rather than treating the reply as permission for every unfinished item.

Desktop execution also needs immediate user control. Stop sending input when the user takes over, release held keys and buttons, and mark the prior observation stale. Resume only after obtaining a current view of the application and checking that the intended operation remains authorized.

This is worth testing with ordinary interface changes. Move the window, switch tabs, change display scaling, and open a similarly named file. The executor should either identify the correct target through a supported route or stop with a specific reason that identifies the failed check, allowing the user to distinguish missing permission from a technical limitation without approving a broader action merely to discover what went wrong.

For the illustrative heading correction, retain the approved change, the fresh target observation, and the final file check. A reviewer should be able to establish that the right document changed without reconstructing the user’s entire conversation. If target identity remains uncertain, leave the prepared edit unapplied and ask which document should receive it.

Source notes

Based on Boris’s specified contract scope and desktop action controls. The changed-document scenario is illustrative; it is not a completed capability demonstration.