What a separate Bot does not separate

The official overview states that Bots on one account share computer files, sessions, and logins. Separate Bot names do not create separate access boundaries. The approval documentation describes model-based Auto Review and explicit action approvals; it recommends combining them with least privilege. Neither a prompt nor an automated review should be treated as an absolute guarantee.

The permission worksheet below is an original operating suggestion. Apply your organization's actual access policies when relevant.

Documentation: Shared computer model ↗ Official approvals and privacy guide ↗

Write boundaries around verbs and targets

'Be careful with email' leaves too much open. 'Read the approved folder and draft replies; do not send, forward, archive, or change labels' identifies observable behavior. Do the same for a database, repository, or publishing system: name the resources and the permitted operation.

For a recurring job, consider three stages. First, gather evidence. Next, prepare a proposed change. Finally, apply a specific approved change if authorized. The evidence and proposal should be useful on their own so a human can decline execution without losing the value of the work.

When credentials are needed, use the service's supported secure sign-in or secret-entry flow. Do not put secret values in the brief, a reusable skill, or an example intended for sharing.

  1. List the systems the task needs and the smallest usable account permissions.
  2. Write allowed operations and prohibited operations in plain language.
  3. Define what an approval request must show: exact target, before/after values, and likely effect.
  4. Use a harmless sample to check that the workflow pauses at the intended point.
  5. Revisit access when you add a Bot, connection, or new responsibility.

A preparation-only brief

Adapt the allowed actions to your actual task. This template does not configure or replace technical permissions.

Try this brief

Work only with [approved sources]. You may read and produce a separate draft artifact. Do not send messages, publish, purchase, delete, modify permissions, accept terms, or alter the source systems. For each recommended change, show the exact target, current state, proposed state, rationale, and uncertainty. Finish the analysis and draft before asking for a decision. If the task requires additional access, explain the specific missing operation; do not broaden access yourself.

Original editorial template. Replace placeholders and review access before running.

Review the effect, not just the explanation

A persuasive rationale cannot compensate for the wrong destination or account. Compare the actual operation with the approved scope. For batch work, check the count and selection rule as well as a sample record. Keep approval narrow enough that you can tell what you authorized later.

  • The target account and resource are recognizable.
  • The proposed change can be inspected before execution.
  • The scope does not silently include unrelated records.
  • Completed changes will be reported separately from pending ones.

Sources & next steps

Capabilities are grounded in the documentation below. The workflow design and acceptance checks are editorial suggestions.

Build your own workflow brief ↗