Bound AI Tool Permissions by the User Task

Separate suggestion from execution

Define which outputs are informational, which are proposed actions, and which actually change product state. A draft action should not become executable merely because it is expressed in fluent language. Describe the supported tools in terms of their real effect, including whether they read data, update a record, or communicate with another person.

In a hypothetical project assistant, “suggest a revised due date” and “change the task due date” are different capabilities. The first can remain a private draft; the second changes shared work. Keep that distinction visible in the interface and the implementation. A user asking for planning advice should not accidentally authorize updates to every task mentioned in the conversation.

Enforce scope and authority at the action layer

The action layer should verify the current user’s permission, the target object, and valid arguments independently of the generated request. Limit available capabilities to what the task needs. Do not rely on a prompt instruction as the only control preventing unauthorized action. Permissions can change between proposal and execution, so consequential changes need current checks.

For the project assistant, a team member may edit their own task but lack authority to change another team’s milestone. Validate the target workspace and task identifier rather than accepting a name match. Keep restricted data out of the tool response as well as the visible interface. A successful action must follow the same product rules as an equivalent manual operation.

Make approvals concrete and inspectable

Show the actual proposed change before asking for approval. Include the object, previous value where useful, new value, and scope. A vague “allow assistant to continue” message gives little basis for a decision. Avoid bundling unrelated actions into a single approval when the person may want to accept one and reject another.

In the due-date example, preview “Move Design Review from Tuesday to Thursday” with the relevant project context. If several changes are proposed, let the user inspect each and understand dependencies. Approval should apply to the reviewed proposal; a later regeneration that changes the target or value may require a fresh decision. Preserve a clear record of what was approved and executed.

Handle outcomes, retries, and reversal

Report whether each action succeeded, failed, or remains uncertain. If confirmation is lost after a request, check state before retrying so the same action is not performed twice. Provide reversal where the product supports it and explain limitations where it does not. Keep operational records appropriate to the task and data boundaries.

For a batch of task changes, partial success should identify which updates were applied and which require attention. Do not present a single cheerful completion message if important items failed. Test stale permissions, invalid identifiers, malformed arguments, and repeated submissions before release. These cases reveal whether the action boundary remains reliable when the generated request is imperfect.

• Separate drafts from state-changing actions.
• Check current permissions outside generation.
• Preview targets, values, and scope.
• Verify outcomes before retrying uncertain actions.

Exercise the action boundary with documents and messages that claim extra authority or request unrelated changes, then inspect tool behavior as well as the final answer.Test AI Features with Untrusted Content