GitHub Copilot Now Connects to 26 Services With One Sign-In Each, Including Postman, Neon and Vercel. Decide What You Let an Agent Touch Before You Click Connect.
On October 28, GitHub put "Copilot connectors" into public preview: GitHub-verified MCP servers that you authorize once with a sign-in, instead of finding a server, installing it and pasting a token into a config file. The supported list has 26 services, and it includes Neon, Vercel, Cloudflare, Sentry and Postman. The setup friction is gone. The decision about what an agent should be allowed to touch is not.
What shipped
A connected service works across the Copilot app, Copilot CLI, VS Code, Copilot in the cloud on github.com or in GitHub Mobile, and GitHub Mobile itself. It is rolling out to all Copilot plans. On Business and Enterprise, an admin has to enable the "Editor preview features" policy first, and an enterprise that uses an MCP allowlist has to add the GitHub-verified servers to it. Copilot keeps you signed in in the background and, per GitHub, uses a connector's tools only when they are relevant to a request. The Copilot app can also run automations that use a connected service on a schedule.
The 26 on the docs page are Airtable, Amplitude, Apify, Atlassian Rovo, Azure Data Explorer, Bitly, Canva, Cloudflare, Composio, Figma, Grafana Cloud, LaunchDarkly, Linear, Lucid, Microsoft Learn Docs, Miro, Neon, Netlify, Notion, Port, Postman, Sentry, Slack, Statsig, Vercel and Work IQ.
What the docs do not say
The connectors reference page does not cover scopes, and it does not say which connectors can write. For a read-only analytics lookup that does not matter much. For Neon, Vercel, Netlify or Cloudflare, it is the whole question, because those are the services where a wrong tool call can change a database or take a deploy offline. GitHub also notes that some services, Slack for example, need an admin on their side to enable MCP access, which at least means some of these are gated twice.
I could not find a statement about how connector sessions are logged on the service side. That is the thing I would want before connecting anything with production access.
How I'd sort the list
Put the 26 into three buckets. Lookup tools, such as docs search, wiki pages and issue trackers: Microsoft Learn Docs, Notion, Linear, Atlassian Rovo, Sentry and Grafana Cloud sit here for me. Their worst case is a leaked read or an unwanted comment. Creative and planning tools, such as Figma, Miro, Canva and Lucid, which carry low risk to your product. And infrastructure, which is Neon, Vercel, Netlify, Cloudflare, LaunchDarkly, Port and Composio. Anything that can change what your users see or what data they have belongs in the third bucket.
The last bucket is where I would slow down, and it connects to this week's other story. Postman's desktop app was reported to install plugins into coding agents without asking, and Postman is also on this list. That is a coincidence of timing, not a link between the two, but it is a good reminder that "verified" describes the server, not what an agent will decide to do with it.
Where this could be wrong
A one-click OAuth flow is arguably safer than what many of us do now: a long-lived API token pasted into a JSON file, readable by every process on the machine. If connectors use scoped, revocable grants, they may be a net improvement. I do not know the scopes, so I cannot say. The preview label also means all of this can change.
What I'd actually do
I would connect exactly one service this week, a lookup one such as Sentry or Linear, run a few real tasks, and then open that service's authorized-applications page to see what Copilot was actually granted. If the grant looks broader than the task, I stop there.
I would keep the infrastructure bucket disconnected until I had seen a scope list or tested against a throwaway project. Neon has branches, and I would point the connector at a scratch database before a real one. And I would treat the scheduled automations the way I treat cron on a server: nothing runs unattended against production until I have read what it does, twice.
Author
Lukas
@lukcombinator