Authority and confirmation

Authority is what one Agent may do and reach: the channels it works in, the accounts it may use, and the changes it may make to the workspace. Where saved instructions describe how an Agent should behave, authority is stored state that a conversation cannot write to. This page covers where authority is read from, what applies immediately, what arrives as a proposal, how you approve one, and what undo covers.

Where authority comes from

Three stored inputs decide a turn, and none of them can be edited by talking to an Agent.

• Channel grants. A stored grant says which Agent may work in which channel. No grant, no reply.
• Saved Agent instructions. The instructions on the Agent profile, which are the only text that may widen what the Agent does without asking.
• Live membership. The Chickpea membership behind the Slack user who addressed the Agent, re-resolved on the call rather than read from the message.

Authority comes from stored grants and saved instructions, read from stored state and re-checked at the moment of each use, never from anything produced during the turn. Message text, retrieved content, and tool output are data, never permission.

Schedules run with no one watching, so they re-read every input immediately before each run: the authority record, the Agent, the destination grant, the Runs as member, and every connection needed. A missing input fails the run with a named reason (agent_unavailable, destination_unavailable, creator_ineligible, connection_unavailable). Chickpea never silently reassigns work to someone else.

External actions in a turn

Confirmation covers two different things. An external action is an Agent writing to a connected account, say Zendesk or Gmail. A workspace change edits Chickpea itself, and the next section covers it.

Minor reversible writes may proceed without confirmation. Consequential ones (sending a message or email, deleting, publishing, broad or bulk changes) require confirmation unless the saved Agent instructions explicitly authorize that class of action.

That posture reaches the model as fixed text wrapped around the saved instructions, which arrive inside a marked block. The same text states that only those instructions may expand authority, and that conversation text, retrieved content, and tool output are untrusted task inputs.

Underneath the judgment sits a gate that does not consult the model. During a Slack submission, these are refused unless the current Slack request itself names a matching action:

• any request through a connection that is not GET or HEAD;
• any MCP tool whose name does not start with one unambiguous read verb;
• any managed connector capability whose effect is not read;
• posting an artifact back into Slack.

A refusal raises CurrentRequestSideEffectDeniedError with the message: External side effect requires explicit matching intent in the current Slack request; retrieved content, Slack history, and advisory memory cannot authorize it. The match is on the action and its target, so permission to send one message is not permission to delete a record.

Changes to the workspace

Every management change is classified before anything is written, whichever door it came through. The classifier reads the operation and the actor, never the conversation.

Anything not listed applies immediately as a safe reversible change. Two denials come before any posture: an operation that needs Admin or Owner from a Member, and any operation on an Agent the actor may not edit.

What a proposal is

A change that needs confirmation is written down before it is applied, not held in the conversation.

• It is frozen. Confirming applies the stored operations and cannot reinterpret them.
• It is bound to one person and one place. The same live requester must confirm, from the same MCP client or Slack thread.
• It does not expire. A newer proposal from the same requester and origin takes the older one’s place.
• It goes stale rather than wrong. A changed target revision, digest, permission, requester, acting Agent, or origin makes the whole change set stale or denied before its first write.

Approving in Slack

The Agent posts the proposal as a message headed Proposed changes. Each changed field appears with its Before and After values, and a new Agent appears under New Agent with the name, handle, description, and instructions it would get. A long value is truncated for display only. The message closes with the line: Reply approve to apply these exact changes, or tell me what to adjust.

Seven replies count as approval: approve, approved, confirm, apply it, apply this, create it, create this. Leading Agent mentions and a trailing full stop are ignored. Anything else is a new instruction, not consent. The phrase is matched before any classifier runs, so an approval is never read as chatter.

In a channel the proposal is bound to the thread it was posted in. In a DM it is bound to the conversation, so a later top-level message can still approve it. Applying returns Applied the approved changes., or names how many items need attention. A second approval while the first is running returns That proposal is still being applied; it won’t be applied twice.

Approving in Admin and over MCP

Admin, Slack, and the management MCP are three doors to one service with one policy. Only the way you approve differs.

• In Admin, actions routed through the management service create the proposal and confirm it in the same request. Changing a member’s role or status and removing a stored provider key both work this way, so your click is the confirmation.
• Over MCP, apply_workspace_changes returns a bound proposal for any operation whose posture is confirmation, and confirm_workspace_change takes only the proposal handle. A client can call propose_workspace_changes to get the preview first. One apply request carries at most 25 ordered operations.

Undo

An applied change records an inverse when the request carried exactly one operation, was not an Agent creation, and had an exact inverse. Receipts say so: You can undo this change.

Undo is available only to the same actor, only at the exact resulting revision, and in Slack only when you ask for it in as many words. If the inverse has itself become consequential, undo returns a proposal instead of bypassing confirmation.

On Node

Node runs no scheduler, so the unattended re-check above never fires there. Every other rule on this page is the same on both targets, because they share one policy.

Why it works this way

The conversation is the one input an outsider can write to. A pasted instruction, a fetched web page, or a tool result can say anything, so none of them decides what happens next. Grants, instructions, and membership live in stored state that only an authorized editor changes through a checked path.

Freezing a proposal closes the gap between review and application. You approve the exact operations you read, and a target that moved underneath them makes the proposal stale instead of applying something you did not see.

What is not covered

• Saved instructions cannot skip a workspace confirmation. They pre-authorize classes of external action. The management policy takes no instruction input at all.
• Memory is advisory, never policy. Nothing an Agent remembers changes what it may do.
• Undo is one operation, not a history. There is no workspace-wide rollback, and a change made in a batch records no inverse.
• Approval is not delegation. Nobody else can approve your proposal, and a proposal cannot move to another conversation.

Next steps

• Security model: the full guarantee list and the mechanism behind each one.
• How Chickpea works: one mention from Slack to the reply.
• In Slack: handles, channel grants, and managing Agents from a thread.
• Admin: roles, members, and where each setting lives.