astradevlabsastradevlabs
← All posts
Dev Tips5 min

FAQ: 6 Guardrails to Set Before You Roll Out GitHub Copilot App and Cloud Agent

Dev Tips

GitHub made two important Copilot governance changes on July 27, 2026: the GitHub Copilot app got its own client policy, and enterprise-managed settings started applying to both the Copilot app and Copilot cloud agent. A few days later, the managed-settings reference also exposed direct MCP allow and deny controls.

That combination changes the rollout playbook. Before July 27, many teams could treat the Copilot app as an extension of Copilot CLI. Now it is its own surface, and it deserves its own guardrails. If you want developers using parallel agent workspaces without turning every repo into an ungoverned experiment, start with these six checks.

1. Do I need a separate policy for the Copilot app if I already govern Copilot CLI?

Yes. That is the first thing to fix. GitHub now treats the Copilot app and Copilot CLI as separate client policies. If your enterprise wants developers to use the app but not the CLI, or the reverse, you can now do that cleanly.

That matters because the app is not just a prettier terminal. It adds parallel workspaces, pull request lifecycle controls, and session modes that range from interactive to autopilot. It is closer to an agent workstation than a shell wrapper. Treating it as a separate surface is the right governance move.

The lazy rule: decide the app policy first, before you debate models or plugins. If you do not want the surface at all, disable it everywhere and stop there.

2. What is the safest default for cloud agent access?

Keep it narrow. GitHub’s enterprise docs say Copilot cloud agent and third-party MCP server usage are disabled by default, and that is the right starting point. Turn it on only for selected organizations or pilot repos first.

The cloud agent is powerful because it can take on background work and land changes through pull requests. That same strength is why broad enablement is a bad first move. The docs also note that once an organization is selected, the agent is available in all repos in that organization unless org owners explicitly block specific repositories.

So the rollout order should be:

  1. Enable for selected organizations.
  2. Block sensitive repos at the organization layer.
  3. Pilot with a small repo set before expanding.

If you invert that order, you will spend the next week cleaning up policy drift.

3. Which managed-settings.json keys matter first?

Do not overbuild the file. Start with the keys that close the biggest holes:

  • permissions.disableBypassPermissionsMode
  • enabledPlugins
  • strictKnownMarketplaces
  • allowedMcpServers
  • deniedMcpServers

A minimal baseline looks like this:

json
{
  "permissions": {
    "disableBypassPermissionsMode": true
  },
  "enabledPlugins": {
    "github": true
  },
  "strictKnownMarketplaces": [],
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.github.com/*" }
  ],
  "deniedMcpServers": [
    { "serverName": "untrusted-server" }
  ]
}

This is intentionally strict. An empty strictKnownMarketplaces array is a full marketplace lockdown. That is usually the right opening posture for an enterprise pilot. You can loosen it later for specific teams.

4. How should I handle plugins and MCP without blocking useful work?

Separate platform-approved integrations from personal experimentation. GitHub’s docs now let you manage plugins, marketplaces, and MCP servers across the Copilot app and cloud agent from one policy file. Use that to create one approved lane instead of a vague ‘be careful’ policy.

For the interactive app, decide which plugins are worth supporting centrally. For cloud agent, focus even more on MCP scope, because MCP is how the agent reaches outside the repo and into systems like Sentry, internal services, or package registries.

GitHub’s cloud-agent resource guide is explicit here: external access only works when repo or org admins configure it. Secrets also need to be stored as Agents secrets, not borrowed from GitHub Actions or Codespaces secrets. That is a good boundary. Keep it.

5. Where should team conventions live: in prompts, skills, or repo settings?

Put durable conventions as close to the repo as possible. GitHub’s Copilot app docs say you can set both global instructions and repository-specific instructions, and that skills configured for repositories or Copilot CLI are automatically available in the app.

That suggests a practical split:

  • Put company-wide guardrails in managed-settings.json.
  • Put repo-specific engineering standards in repository instructions.
  • Put reusable task behavior in skills.

Do not stuff everything into a single global prompt. That looks simpler on day one and becomes unmaintainable on day ten.

6. What should I verify before expanding from pilot to broad rollout?

Check three things, in this order:

  • Policy coverage: the app policy, cloud-agent policy, plugin policy, and MCP policy should all reflect the same intent.
  • Repo boundaries: sensitive repos should be blocked explicitly, not just ‘understood’ socially.
  • Escape hatches: confirm whether bypass-permission behavior, marketplace installs, and MCP additions are actually restricted the way you think they are.

The biggest recent change is not that Copilot got more capable. It is that GitHub gave admins better knobs to make those capabilities predictable across surfaces. Use them.

If you want one rollout heuristic, use this: enable the client surface deliberately, allow the smallest useful set of plugins and MCP servers, and keep repo-level instructions close to the code. That gets you most of the benefit of agent workflows without pretending every team needs full autonomy on day one.

References