GitHub Copilot in Slack and Teams: what happens to the conversation?

A SaaS team is discussing a customer bug in Slack. The thread contains a screenshot, a log excerpt with a user’s email address and an agreement on the fix deadline. A developer mentions @GitHub and asks Copilot to create an issue or a pull request, or PR, proposing a code change. How much of that conversation can the agent use, and what could later appear in GitHub?

This is a hypothetical example, not a client matter. It matters because GitHub expanded the Slack and Microsoft Teams integrations on 25 September 2026. Copilot can use supported Slack files, attachments and message links. In Teams, it can work with inline images, forwarded messages and channel or thread history. GitHub also links created work back to the source discussion. The integrations remain in public preview, and some capabilities are rolling out gradually.

What you will learn

In brief

• In Slack and Teams, Copilot uses the whole thread as context. GitHub says that context is stored in the artifacts the agent generates. This does not mean every message is necessarily copied verbatim.
• A user needs repository write access to trigger code changes. Other conversation participants can contribute context, subject to GitHub’s restrictions on workspace guests and outside repository collaborators.
• An agent-created PR still needs human review and a human merge. That control does not prevent customer data from appearing earlier in an issue or PR description.
• Before starting, check the thread, target repository, access to generated artifacts and your customer commitments.

Does Copilot read only the message containing @GitHub?

No. In a shared conversation, the entire thread is the starting context. GitHub says this in its Slack guidance and Teams guidance. It also says that the context is stored in the agent-generated artifacts, which can include issues and PRs. The documentation does not promise a word-for-word copy of every message. The practical point is that material earlier in the thread can shape a GitHub record even if the final instruction does not repeat it.

In the hypothetical SaaS thread, the prompt says only “fix the import bug”. Earlier messages contain a production log with an email address and a commercial commitment to the customer. The agent can use both as context. After the September update, supported Slack attachments and Teams images or forwarded messages may also add context. Confirm the formats and features available in your own workspace: preview behaviour can change, and the rollout is gradual.

If the task needs only a short bug description, start a fresh thread with a clean summary or send the GitHub app a direct message. Both GitHub guides recommend a direct message when you want to limit context. In Slack, the agent also opens a dedicated Slack Code channel for a task. GitHub says an archived channel remains viewable and searchable, so include that history in your access review.

Who can initiate work, and who can influence it?

A person needs write access to the target repository to trigger the agent to make changes. Someone else in the conversation can still add information that the agent uses. GitHub says workspace guests and outside repository collaborators cannot start or steer a Slack or Teams session. The Slack and Teams instructions state these limits separately.

For a CTO, the distinction is straightforward: permission to start a task is separate from control over every fact in its context. One participant might paste an outdated customer requirement, while the developer with write access requests an implementation. Copilot can see both. State the current decision, target repository and task boundaries clearly, then review the assumptions in the agent’s output.

The actor creating GitHub artifacts also changes with the setting. In a direct message, Copilot acts using the linked person’s GitHub permissions. In a shared channel or group thread, it creates artifacts under the app’s identity. GitHub says a ruleset that already requires at least one approval can require an additional approval for an app-authored PR. Check the actual review rules in your repository before relying on a particular approval path.

What if the thread contains customer information?

First decide what the agent actually needs. A ticket reference, error description and expected result may be enough. A user’s email address, full production screenshot or negotiated customer price may add no value to the fix. If those details remain in the thread, they can influence the issue or PR the agent creates. Review who can see the destination repository and the new artifacts, then inspect their descriptions, comments and code diff for unnecessary information.

For personal data within the GDPR’s scope, the GDPR’s data minimisation and security principles require a purpose-specific assessment and safeguards proportionate to the risk. If a SaaS provider processes customer data on a client’s behalf, check the client’s instructions and contract. Assess whether this particular use adds a further processor requiring authorisation and appropriate downstream terms. The word “integration” alone does not determine the parties’ GDPR roles. Confidentiality commitments and trade secrets require a separate contractual and access review.

There is also a second copy of the information to consider. A GitHub issue or PR has its own readers and history, and the September change can leave a link back to the source conversation. The AI vendor contract checklist covers provider assessment more broadly. Here, the extra control point is the move from a messaging tool into a repository workflow.

Is reviewing the PR enough to protect the data?

Not if the team reviews only code. GitHub says its cloud agent cannot merge a PR or push to the default branch. Its risk guidance requires a human to review and merge agent-created PRs. This gives the team a chance to check code, tests and assumptions before a change reaches the default branch.

The customer email or confidential commercial detail could already be in an issue or PR description. Review those artifacts and their visibility as well. If information was disclosed unnecessarily, closing the PR may leave copies in the record. Trace where it was stored, limit access and follow the organisation’s incident process where the circumstances call for it.

How should a SaaS team or software supplier pilot this?

Start with one task using test data. Check five things:

1. Access: Is the cloud agent and its sandbox enabled? Which repositories can the app use, and who has write access? GitHub describes the Slack prerequisites and Teams prerequisites.
2. Context: Does the test thread contain only what the task needs? Include supported attachments in Slack and images or forwarded messages in Teams.
3. Destination: Which repository will receive the issue or PR? A shared channel can have a default repository, so identify the intended destination explicitly and confirm it before work is created.
4. Review: Who checks the issue, PR description and code, and who can merge the change?
5. Commitments: Could the real workflow involve customer data or confidential information? Check the relevant contracts and internal policy before repeating the test with live material.

After the pilot, write a short rule the team can use: which requests may go to the agent, what to remove from a thread, who reviews the result and which repositories are in scope. If similar integrations are appearing across teams without a common decision, the shadow AI governance guide gives a wider framework.

A team can run a test-data pilot with clear permissions and review ownership. For customer records, repositories shared with third parties or strict confidentiality terms, assess the data flow and contracts first. If you need help with that review, contact Lis.Legal or see our SaaS legal support.