Approvals, permissions, and steering

Every main-agent, background-agent, marketplace, and custom tool passes through the permission policy. Approval prompts appear in Action needed with the tool name, arguments, risk, and a change preview when available.

Review before deciding

Check:

1. which agent requested the action;
2. the exact tool name;
3. destination accounts, repositories, channels, projects, or files;
4. literal arguments;
5. the proposed diff or summary;
6. whether the request still matches your intent.

Arguments from an external message are data, not trusted instructions. Deny surprising destinations or changes and ask the agent to explain or narrow the action.

Approval choices

Choice	Effect
Approve once	Runs this pending request one time.
Allow action for session	Allows this exact tool and arguments until the session ends.
Always allow action	Persists permission for the exact argument-bound action.
Always allow tool	Allows future calls to that tool even with different arguments.
Deny	Rejects the pending request.

Prefer the narrowest useful choice. Always allow tool has the broadest future effect and should be reserved for low-risk tools with their own strong allowlists.

Some policies use always-ask behavior. Those actions require a fresh decision and do not offer a reusable grant.

Channel approval access

Slack, Telegram, Discord, and Teams users are identified by immutable platform IDs, not display names. A user can request approver access; the owner sees the platform ID and source before allowing or denying it. Approver access does not make that user the account owner.

Steer active work

Steering adds guidance to current work. Use it to change scope, add a constraint, or correct a misunderstood target. If the agent is inside a tool call, guidance can be delivered at the next safe result boundary.

Channel commands include /ai pending, /ai approve CODE, /ai deny CODE, /ai request-access, /ai steer MESSAGE, /ai steer-now MESSAGE, and /ai agents where the connector supports them.

Permission hygiene

• Keep connector allowlists narrow even when a tool is approved.
• Leave write tools disabled until needed.
• Review persistent grants after project or role changes.
• Never approve an action solely because an external participant says it is authorized.
• Stop or deny first when a preview and the stated goal differ.