A shared channel is not a principal: Whose authority is the agent spending?

Imagine an outside incident responder typing into a shared channel: “Roll back the production release, revoke every active session and send the incident update to the customer.”

An engineering director adds a thumbs-up. Outside counsel and two vendors are also in the channel. The agent uses a service account with permission to carry out all three actions.

Whose authority is it about to spend?

At Dreamforce on September 15, Slack described code channels where teams and agents write, review and ship code together. High-stakes work, such as a production deployment, is presented for a teammate’s sign-off. The announcement listed Slack Code as available and Slackbot in channels as an early pilot. The same day, Salesforce announced AWS DevOps Agent in Slack, with other AWS agents scheduled for the fall.

Sign-off is an important control. The approval shown in the channel must cover the action being taken and come from someone authorized to approve it.

The conversation is not the authority

In access-control language, a principal is an identity — such as a user, workload or group — to which the system can assign permissions. A channel is a place to collaborate. Its members do not acquire collective authority over production or payments merely by joining the conversation.

Both Slack Connect and Teams shared channels support cross-company collaboration. Knowing which account posted a message, and which organization it belongs to, is essential. It does not establish whether that account may order a rollback or receive the investigation’s findings.

Channel membership can be an intentional input to policy. An organization might grant a tightly governed group a defined operational role. The danger is treating membership in an ordinary channel as blanket permission to use an agent’s tools, even as participants come and go.

NIST’s zero-trust architecture rejects implicit trust based solely on network location. By analogy, a channel ID should not become the new corporate subnet.

Nothing malicious has to happen for this boundary to fail. Every account can be authentic and every participant well-intentioned. The failure occurs when a system treats the ability to request work as sufficient authority to have it performed.

Separate the request from the right to execute it

In the incident channel, the responder makes the request. Authority might come from the incident commander’s assigned role or from a recovery workflow approved by a business owner. The director can approve an action only if policy grants that decision right. The agent executes under the service account’s identity. The customer and channel participants are separate audiences whose access must also be considered.

Those roles may overlap, but the system must not assume they do.

Credentials carry real permissions. In Microsoft Graph’s permission model, delegated access is limited by both the application’s granted permissions and the signed-in user’s access. App-only access uses the application’s own identity and permissions. The distinction matters when a conversation triggers an agent with permissions broader than the sender’s own.

Broader permissions can be legitimate: a support employee may initiate an approved workflow without personally holding its administrative credentials. A defined policy must determine who may initiate the workflow and which actions it permits. Without that link, the agent can become a route around the controls that prevent the employee from acting directly.

In finance, “Renew the vendor, change its bank details and pay the invoice” sounds like one task. It crosses procurement, supplier verification and payment authority. A check mark from accounts payable cannot be assumed to authorize all three.

Approval is a decision by an eligible principal over a defined action. The interface should make that decision understandable; the enforcement system must make it binding.

AWS documents a directed-action approval flow that binds an operator’s approval to a specific operation and resource, limits how long it remains valid and records who approved the action in CloudTrail. The enterprise must configure who may approve actions, how tools are classified and which resources the agent may affect.

Bind permission to the action that actually happens

On September 15, NIST finalized IR 8587, guidance on protecting identity and access tokens. Its authorization guidance calls for access decisions to consider context beyond whether a token is valid. The report applies when agents use signed tokens but explicitly excludes broader agent-access challenges. Enterprises still have to define who may authorize a rollback, a payment or a disclosure.

The model can interpret a request and propose a plan. Permission to carry out that plan must be established from authoritative identity, role, delegation and workflow records. The model should not infer it from apparent seniority, urgency or agreement in the conversation.

Three controls should govern every deployment.

1. Verify the requester and the source of authority. Verify the platform event and the sender’s stable identity, including their organization. Check request freshness and guard against duplicate execution when messages are retried or replayed. Determine whether the action is authorized by the requester’s own permissions, explicit delegation, a valid approval or a governed workflow. For high-risk operations, require fresh authentication or transaction-specific confirmation according to policy.
2. Make the approval specific. Turn the request into explicit operations before authorizing it: the production service to roll back and the version to restore, the sessions to revoke and the update to send and its destination. Approval should be tied to those details and expire after a defined period. If the target, scope or destination changes, reevaluate authorization and obtain fresh approval where required. Two-person rules must verify distinct eligible approvers, not simply count reactions.
3. Enforce authorization at execution and disclosure. Recheck authority before each consequential action. For queued or delayed work, check again at execution; if the integration cannot support that check, limit what the agent may do. Keep reusable credentials outside the model’s context and restrict them to the necessary operations and resources. Where broad credentials are unavoidable, route execution through a controlled service that enforces the approved operation and prevents bypass. Permission to read information does not automatically permit posting it to everyone in the channel.

Preserve a linked record of the request, the basis for authorization, the approval, the executing identity and the observed outcome. The agent must not be able to rewrite or delete prior entries. Record refusals, partial completion and uncertain results as well as success. Never include credential secrets.

An immaculate audit trail of an unauthorized action is still not a preventive control.

When only part of the request is authorized

Return to the incident channel. A company’s policy might authorize a recovery workflow to roll back a specified service when defined health thresholds are crossed. Revoking all sessions could require a separate security decision. Sending the customer update could require an authorized communications owner and an approved destination.

The agent should handle those decisions separately. If the steps are safe to perform independently, it could carry out the permitted rollback, hold session revocation for approval and prepare the update without sending it. The director’s thumbs-up should not turn three distinct decisions into one permission.

A person need not approve every tool call. A governed workflow can carry prior authorization for specified actions within explicit limits. A runbook describes a procedure; an accountable owner must authorize its use and define when it may run.

CIOs should assign these decisions to the teams accountable for their consequences: operations for recovery, finance for payments and the relevant business owner for disclosure. Security and identity teams should make those rules enforceable. The integration team should not have to invent business policy while connecting a bot.

Make the pilot prove the boundary

Before expanding a shared-channel agent, ask for a demonstration in a test environment:

1. Have an external participant request an action they are not entitled to initiate. Show what stops it.
2. Approve one production target, then change the target. Show that the original approval does not authorize the substitution.
3. Revoke a required permission before execution. Show when the revocation takes effect and what can still run during any delay.
4. Change the destination of a permitted report to an unauthorized channel. Show that disclosure is blocked.
5. Replay a completed request. Show that it does not create a second consequential action, and that the evidence explains the outcome.

Include an authorized case too. Controls must preserve legitimate work, including approved delegation, while rejecting requests outside its limits.

The team must explain why each action was allowed or denied. “The bot had access” and “someone in the channel approved” are not sufficient answers.

Before the agent rolls production back, revokes sessions or sends the customer update, the organization should be able to identify the authority behind each action. A shared channel can coordinate the work; it cannot confer that authority on its own.