Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · November 8, 2026 · concept

GitHub CopilotGoldman Sachsagent-securityagent-identitycodexclaude-code

Coding Agents in Slack Aren't an Access Problem. They're a Review Problem.

GitHub just put its coding agent in Slack and Teams. Here is a simple merge path that makes sure someone who understands the code approves it.

A pull request used to have an author who could explain it. Someone wrote the code, someone else read it, and if the reviewer asked "why did you do it this way?", there was a person on the other end with an answer.

That chain breaks the moment the author is an agent and the person who asked for it can't read code. And that moment just got a lot closer. On November 6, GitHub made @GitHub in Slack and Microsoft Teams generally available: from a chat thread, you can investigate a bug, open an issue, have the agent implement a change and get a pull request back.

The people in those threads are not all engineers. So the useful question is no longer "should we give people a coding agent?" It is "who reviews what the agent builds, and how do we make sure they do?" The answer this piece lands on is short: anyone with write access can ask, and a code owner must approve.

Two directions in the same week

The same week GitHub pushed agents into chat, a story about the opposite move hit the Hacker News front page. Bloomberg reported, in coverage relayed by State of AI on November 2, that Goldman Sachs updated internal guidance in October to restrict Claude Code and GitHub to its engineers, "following a review of productivity and risk concerns." Traders and bankers who had used the tools to track client flows and build market models lost access. Strats, who sit between trading, research and engineering, kept it, according to a second person familiar with the matter.

Goldman's spokesperson said only that the bank makes certain AI tools available "to determine the best use cases." The sourcing is anonymous, and Bloomberg's original was not something we could load, so don't read more into the bank's motives than "productivity and risk."

Still, look at where the line fell. The people who kept the agent are the people who can read what it writes.

The real problem: code nobody understands

A Finnish developer named Kristian Polso published "Why I will not be using LLMs in my coding" on November 8, and one of his dealbreakers is maintainability: code that no human on the team actually understands. You can disagree with the rest of his list and still recognize that one.

Here is the thing. That risk doesn't depend on who typed the request. An engineer who rubber-stamps an agent's 600-line diff has the same problem as a banker who can't read it at all. The difference is that the banker can't even pretend.

So banning non-engineers treats a symptom. The cause is a merge path where nobody who understands the change has to approve it.

What GitHub already enforces

This is where it gets practical, because GitHub has been building the review side of this for a while. Three controls matter.

The agent can't approve its own work, and neither can the person who asked. GitHub's risks and mitigations page for Copilot says Copilot's cloud agent cannot approve or merge a pull request, its draft PRs (pull requests marked as not ready to merge) must be reviewed and merged by a human, and GitHub prevents the user who asked Copilot to create a PR from approving it. The agent also stays subject to your branch protections (rules that block a merge until conditions such as approvals or passing tests are met) and required checks.

That last rule is the interesting one. If a product manager asks the agent for a change from Slack, the product manager cannot be the approval that ships it. Somebody else has to look.

Unattributed agent PRs need an extra approval. In rulesets, GitHub's newer way to protect branches, a public-preview rule called "Require an additional approval for unattributed Copilot pull requests" is on by default. When Copilot opens a PR that isn't attributed to a person, the ruleset requires one more approval than you configured. Require one, and it takes two.

Code owners get pulled in automatically. A CODEOWNERS file maps folders to the people responsible for them. Code owners "are automatically requested for review when someone opens a pull request that modifies code that they own," and you can require their approval before merge.

Put those together and you get a simple model: anyone with write access can ask, an owner must approve.

A role model that doesn't need a ban

Instead of "engineers yes, everyone else no," split the job into three roles.

  • Askers can start agent work from a chat thread. GitHub only lets people with write access to the repository trigger Copilot's cloud agent, so this is everyone you have granted write access, which may reach well past the engineering team.
  • Reviewers must approve what the agent built before it merges. These are code owners for the files touched, and never the asker.
  • Scopers decide which repositories accept chat-originated work at all. Your pricing engine and your marketing site are not the same risk.

This is closer to Goldman's line than it looks. The strats who kept access are people who can read the output, whatever the bank's actual reasons. In this model, anyone with write access can ask, and the people who can read the output hold the merge button.

What a reviewer should check on a PR from chat

A PR that started in a chat thread is a different animal from one an engineer opened. The request was probably one or two sentences, typed between meetings. The agent filled in everything else. So the review has a different first job: figure out whether the agent built what the person meant.

Five questions cover most of it.

  1. Does the change match the ask? Agent PRs from chat carry a line naming the conversation and the person who asked (more on that below). Open that thread and read the original request. Agents tend to solve a slightly larger problem than the one they were given.
  2. What did it touch that nobody mentioned? Scan the file list before the diff. A copy change that edits a config file, a lockfile or a CI workflow deserves a question.
  3. Did it add or change tests? If the answer is no, ask why, and ask the agent to add them in the same PR.
  4. Is anything secret or environment-specific in the diff? Tokens, URLs to internal hosts and hard-coded account IDs show up more often when the asker pasted context into chat.
  5. Could you explain this change to the next person? If you can't, don't approve it yet. That is the whole point of being the reviewer.

None of this needs new tooling. It needs a reviewer who knows the PR came from chat and treats the first question as the important one.

Put this into practice

You can set this up in an afternoon on one repository.

1. Require pull requests for the branch that matters. In the repository's rulesets, turn on "Require a pull request before merging" for your default branch, and require at least one approving review. GitHub's docs note that a PR "doesn't necessarily have to be approved, but it must be opened" under the base rule, so add the approval count too.

2. Add a CODEOWNERS file. Put it in .github/, the repository root or docs/ (GitHub checks those in that order and uses the first it finds). A small one covers a lot:

# .github/CODEOWNERS
*                 @your-org/platform-team
/billing/         @your-org/billing-owners
/infra/           @your-org/sre

Then turn on the option to require review from code owners. Now a change to /billing/ can't merge until someone on the billing team approves it, no matter who asked for it. Two details trip people up: code owners need write access themselves, and they aren't requested on draft PRs until the PR is marked ready for review.

3. Leave the extra-approval rule for Copilot on. It is enabled by default in rulesets. Check that nobody turned it off to "speed things up." When your ruleset requires at least one approval, this rule adds one more. It does nothing if the ruleset requires zero, which is one more reason to set a real approval count in step 1.

4. Use the provenance line. Since the November 6 release, issues and PRs created from chat carry "Created from a Slack/Teams conversation with @username." That gives reviewers a person to ask. Make it a team habit: if the PR came from chat, the reviewer pings the asker with one question about intent before approving.

5. Pick your scope on purpose. Start with one or two low-risk repositories open to chat-originated work. Expand after a few weeks of seeing what comes through and how long review takes.

What to expect: more small PRs, and more of them waiting on reviewers. That queue is the point. It is where the understanding happens.

Honest limitations

  • Review is only as good as the reviewer. A code owner who approves without reading defeats every control above. Required approvals measure clicks, not comprehension.
  • These controls are GitHub's. If your team runs Claude Code or Codex against a different host, or pushes straight to branches, you need the equivalent rules there.
  • Some of this is in preview. The extra-approval rule for unattributed Copilot PRs is public preview, and preview features change.
  • Plans differ. Rulesets and code-owner enforcement depend on repository visibility and your GitHub plan; rulesets on private repositories need a paid plan. Check the rulesets docs against your account before promising anything to the team.
  • Bypass lists exist. Rulesets can name users, teams or apps that may skip the rules. Audit that list, or your merge path has a side door.
  • The Goldman details are secondhand. The reasons beyond "productivity and risk" are other people's inference, not the bank's.

What to do with this

Agents in chat are going to spread whether or not your company writes a policy about it, because the chat window is where requests already live. You can respond with a ban, like the version of events Bloomberg described, or with a merge path that makes understanding mandatory.

Pick one repository this week. Add CODEOWNERS, require a PR and an owner's approval, and let one teammate outside engineering who already has write access try asking the agent for a small change. Watch who ends up reading the diff. That person is your real policy.

Sources: GitHub changelog, @GitHub in Slack and Teams GA (November 6, 2026), State of AI relaying Bloomberg (November 2, 2026), GitHub Copilot risks and mitigations, GitHub rulesets: available rules, About code owners, Kristian Polso (November 8, 2026).