Write Access Decides Who Starts the Agent, Not Who It Hears

GitHub put Copilot cloud agent sessions inside Slack and Microsoft Teams on 21 August, both in public preview. You mention the GitHub app in a channel, a thread, or a direct message; the agent works asynchronously in a cloud sandbox and posts back an issue, a plan, or a pull request when it has one. The Slack version runs on Copilot Business and Copilot Enterprise and draws on existing Copilot entitlements. The Teams version additionally needs Microsoft Public Developer Preview switched on in the Teams client. Both require an organization owner to have enabled the Copilot cloud agent policy and cloud sandboxes first.

The access rule is one sentence in the integration docs, and it reads like a complete answer. Only users with write access to a repository can trigger Copilot to make changes. Guest members of a Slack workspace and outside collaborators on a repository cannot start or steer a session at all.

The next sentence is the one that matters. Any participant in the conversation can provide input, and the agent uses all the messages in the conversation to inform the work. The entire thread is the decision-making context.

The access control boundary is not the context boundary

Those two rules describe two different surfaces, and only the first one is enforced by a permission check.

The first is a capability gate: can this identity cause a write. Repository write access answers it, GitHub checks it, and a contractor sitting in the channel as a single-channel guest fails it. That part behaves the way an access control review expects.

The second is an input surface, and it has no permission attached. Every message in the thread becomes part of what the agent reasons over. The guest who cannot start a session can still type into the thread where a session is running, and that text lands in the same context as the instruction from the person who could.

This is not an exploit, and it is not buried: the integration docs state both rules plainly, on the same page. It is a modelling gap. Access control lists answer the question of who may act. They do not answer the question of whose words reach the thing that acts. A chat surface pulls those two questions apart, because a Slack channel is a room, not a role.

The identity split downstream makes the asymmetry concrete. In a direct message, the agent uses your linked GitHub account and your permissions. In a channel or a thread — the shared context, the one with everybody in it — it acts under the app identity instead. Pull requests it opens there carry no personal attribution, and the docs note the consequence: in a repository whose rulesets already require approval, one more approval is needed before such a pull request can merge. The changelog presents that extra approval as a compliance feature. The docs present it as what falls out of an unattributed author. Both are true; only the second tells you it is not a setting you chose.

For teams that have been treating agent rollout as a licensing exercise, this is the same shape as the failure described in why enterprise AI does not ship: the model works, and the integration is where the assumption breaks.

What to change this quarter

The specific decision: set repository access before you enable the policy, not after. The organization setting under Copilot then Cloud agent defaults to All repositories once the policy is switched on. Selected repositories is the other option in the same control, and choosing it before the flip is a setting; choosing it afterwards is a migration. Enterprise owners and organization owners can also block the agent in specific repositories, and individual users can opt their personal repositories out.

Three checks that follow from it:

• Count the non-employees in every channel where the GitHub app is installed. Slack allows up to five single-channel guests per paid member at no extra cost, so a channel can accumulate them without ever showing up on a seat bill. Guests can read message and file history in the channels they are in, so the thread the agent reads is the thread they have been reading.
• Confirm the approval requirement exists on every repository the agent can reach. The extra approval on app-identity pull requests only appears where a ruleset already requires approvals. On a repository with no such rule, the app-identity pull request needs zero.
• Pin a default repository per channel in Teams. Without one, the agent falls back to the default repository or the first repository used in that channel — a resolution order, not a decision.

The rest of the containment is already in place and worth knowing before you argue about it: the agent works one branch at a time, is capped at 59 minutes of execution, cannot reach other repositories or organization secrets, runs behind a firewall enabled by default, and signs its commits. GitHub's responsible-use page names one input-poisoning control, a filter for hidden characters used to conceal instructions in comments and issue contents.

What would show this is wrong

The claim is that channel membership, not repository permission, decides whose text reaches the agent. It fails if GitHub documents that messages from participants who cannot steer a session are excluded from context, or ships a setting that scopes the context to the triggering user. Either would move the input surface back behind the permission check, and the guest inventory above stops mattering. Until one of them exists, the honest statement to put in a rollout doc is that the room is the boundary.

If your current control is a policy sentence saying only authorized engineers may direct agents, that sentence is now describing the trigger and nothing else. Go count the guests.