Copilot in Teams and Organizations: Policies, Content Exclusion, Model Access, Usage Metrics, Cost and a Comparison with Claude Code/Codex

Version note: The scripts in this post were run with .NET 10; the content exclusion YAML files were checked by parsing them with yq 4.54, and managed-settings.json with jq 1.8. Policies, content exclusion, enterprise managed settings, usage metrics, the audit log and budget controls are taken from docs.github.com as of 15 November 2026; no organization or enterprise account was configured for this post. The cost table is an estimate built on the session calculation from the first post and the review averages in the documentation.

Guess First

On the team behind Bookstore, the online bookstore used as the shared example across this site's series, eight developers use Copilot Business. Each opens four agent sessions a day (Claude Sonnet 5.5, thirty steps), opens twelve pull requests a month, and the ruleset from the eighth post runs a Balanced code review on every push.

What is your guess? What fraction of the month does the shared pool of 15,200 AI Credits cover? Do agent sessions or code review take most of the monthly credits? Roughly how big is the extra bill? The table in the middle of this post answers all three.

The Layers of Copilot in an Organization

On Copilot Business and Enterprise, settings live in three layers: enterprise, organization and repository. The enterprise enables or disables most policies, or leaves them to organizations with "Let organizations decide"; once the enterprise has chosen, the organization cannot change it. A policy is the rule of wherever you get your license: if a user gets licenses from two organizations in the same enterprise, usually the least restrictive setting applies; if from different enterprises, almost always the most restrictive. A user's individual plan is cancelled when they are added to a Business or Enterprise plan, so their personal settings do not conflict with the organization's.

Policies can apply on every surface where a user signs in to Copilot, meaning the IDEs, the GitHub website and Copilot CLI, but not every policy applies on every surface. GitHub's "Supported surfaces for GitHub Copilot policies" table lists this policy by policy. Two separate policies also decide whether newly GA features and models arrive enabled or disabled by default.

Policies: Features, Models and Previews

Under Copilot in the organization settings there are two pages. The Policies page manages features and privacy settings, the Models page manages access to models beyond the basic ones; the models on the second page can add cost. Some of the policies we touched on in this series:

• MCP servers in Copilot: whether MCP servers can run at all in Copilot clients. GitHub recommends keeping it on and limiting the permitted servers with an allowlist.
• Copilot code review and code review for members without a license: the two settings that turn on the review from the sixth and eighth posts and, on Business and Enterprise, open it to unlicensed members.
• Allow use of Copilot CLI billed to the organization: required for the CLI workflow with GITHUB_TOKEN from the ninth post.
• Editor preview features, Copilot can search the web, Copilot Memory, Suggestions matching public code, and Configure custom models, which allows bringing your own model provider.

A note on the Models page: as we saw in the eighth post, code review does not let you pick a model, and according to the documentation it may use models that are not enabled on the Models page; that page only manages Copilot Chat. On Business and Enterprise, turning on "Opt in to preview features" lets users try features that are not GA yet; preview features may change or be removed. Max review effort, ACP and custom agents in JetBrains, all mentioned in this series, are in preview as of 15 November 2026.

Content Exclusion

Content exclusion hides the given files from Copilot: inline suggestions do not work in them, their content does not feed suggestions or answers in other files, and code review does not review them. Chat and agents in Visual Studio, VS Code and JetBrains IDEs, Copilot CLI, Copilot in the cloud and code review support it; in Xcode and Eclipse only the inline suggestion side is covered. Repository administrators can write rules for their repository, organization owners for the users they license. We prepared two drafts for Bookstore:

# Paste into the repository: Settings > Copilot > Content exclusion, "Paths to exclude in this repository".
# Content exclusion is for sensitive content, not for context size (use search.exclude for that).
- "/.env"
- "*.pfx"
- "appsettings.Production.json"
# Anonymized order exports used for debugging still contain real addresses.
- "/data/exports/**"

# Paste into the organization: Settings > Copilot > Content exclusion, "Repositories and paths to exclude".
# "*" also covers files outside Git, such as the user-secrets store of every developer. Patterns are case-insensitive.
"*":
  - "**/.env"
  - "**/usersecrets/**/secrets.json"
bookstore:
  - "/data/exports/**"

The "*" key in the organization rule also covers files outside Git. Bookstore's connection string lives in user-secrets, as in the README, which means outside the repository, in every developer's user profile; a repository-level rule cannot see it. Patterns use fnmatch and are case-insensitive; our first draft had a separate line for UserSecrets on Windows, which we removed after reading the documentation again. We checked the files by parsing them as YAML, but did not paste them into an organization to try the result.

Knowing the limits is essential. The documentation says plainly that content exclusion is not a filesystem security boundary: it is a guardrail for the tools GitHub controls, and third-party MCP servers and clients are not bound by it. In agents it blocks access through Copilot tools and checks identifiable file paths in commands, but may not catch indirect access. Indirect content such as type information from the IDE can still reach the model, symlinks and remote filesystems are out of scope, and a change can take up to 30 minutes to reach IDEs. And unlike search.exclude from the third post, it is not a context-size tool: if you exclude generated files, code review will not see them either.

Managing the Client: Managed Settings

Policies answer "which feature is on". How the client behaves (which commands are denied, which MCP servers may run, whether the sandbox is mandatory) is decided by enterprise managed settings. managed-settings.json goes into the copilot/ folder of the enterprise's .github-private repository and is distributed to Copilot CLI, VS Code, the GitHub Copilot app, Copilot in the cloud and JetBrains IDEs; not every client supports every key. The same settings can also be delivered through MDM or as a file in a fixed location in the operating system; when sources conflict, MDM wins first, then the server, then the file. A draft for the Bookstore organization:

{
  "model": "auto",
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Shell(dotnet ef database update *)",
      "Shell(git push --force *)",
      "Read(~/.ssh/**)",
      "Read(~/.microsoft/usersecrets/**)",
      "Read(~/AppData/Roaming/Microsoft/UserSecrets/**)"
    ],
    "ask": [
      "Shell(git push *)"
    ]
  },
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["dotnet", "run", "--project", "src/Bookstore.Mcp", "--no-build"] },
    { "serverCommand": ["npx", "-y", "@playwright/mcp@0.0.85", "--isolated", "--allowed-origins", "http://localhost:4200"] }
  ],
  "sandbox": {
    "enabled": true,
    "allowBypass": false
  }
}

With disableBypassPermissionsMode set to "disable", --yolo and --allow-all have no effect at CLI start-up and global auto-approve is turned off in VS Code; for this key the most restrictive layer wins. deny rules apply from every source and cannot be bypassed; this does at the organization level what the hook in the sixth post did. allowedMcpServers matches local servers exactly by command and arguments; there are no wildcards. To see what that means in practice, we added a rule to the check script from the fourth post that asks whether every server in .mcp.json is on the allowlist:

$ dotnet run eng/check-instructions.cs
...
.mcp.json: bookstore -> in the managed MCP allowlist
.mcp.json: playwright -> in the managed MCP allowlist
Always loaded (AGENTS.md + copilot-instructions.md): 2,334 characters, budget 8,000
OK

# after changing @playwright/mcp@0.0.85 to 0.0.86 in .mcp.json
$ dotnet run eng/check-instructions.cs
...
.mcp.json: playwright -> NOT in the managed MCP allowlist
Always loaded (AGENTS.md + copilot-instructions.md): 2,334 characters, budget 8,000
error: .mcp.json: server 'playwright' (npx -y @playwright/mcp@0.0.86 --isolated --allowed-origins http://localhost:4200) is not in eng/copilot/managed-settings.json allowedMcpServers
1 error(s)

Bumping Playwright's version by one also requires updating the allowlist; otherwise the server is blocked for everyone in the organization. Running this check in CI makes the pull request that bumps the version bring the allowlist change with it.

Usage Metrics and the Audit Log

Copilot's usage metrics come in three dashboards (usage, code generation, impact) and in REST APIs and NDJSON exports at enterprise and organization level. What they measure: active users, which features are used, acceptance rate, suggested and added lines, and how long pull requests take to open and merge. The documentation says plainly not to read these numbers as a productivity measure: look at patterns, not a single number, and combine them with developer feedback. The comparisons in the impact dashboard show, in GitHub's own words, associations rather than causation. We covered in detail why acceptance rate misleads and which measures mean more in the sixth post of the AI-Assisted Development series.

Two practical notes: a day's data arrives within two full UTC days after the day closes, and because the same user can be in several organizations, do not add up organization totals to get an enterprise total. The metrics measure activity, not license assignments.

To see what agents did, there is the audit log. In the enterprise audit log, the actor:Copilot filter shows agent events from the last 180 days; the events carry actor_is_agent and agent_session_id, which points to the session that produced the event, and the person who started the work is in user. You can trace which session the cloud agent pull request from the seventh post came from here.

The AI Credits Budget

On Business and Enterprise every license adds credits to a shared pool: 1,900 AI Credits per Business license per month, 3,900 per Enterprise license; once the pool is used up, metered usage begins. Budget controls exist at four levels. A user-level budget always hard-stops the credits one person can spend in a billing cycle; a 0-dollar budget immediately blocks features that spend credits. Cost center and organization budgets limit metered spending after the pool is exhausted; for cost centers, included usage controls stop a team from drawing more from the pool than its own licenses bring in. We calculated the numbers from Guess First with a script:

#:property PublishAot=false
// Monthly AI Credits of a team against the shared pool of Copilot Business or Enterprise.
// Session credits: eng/ai-credits.cs (30-step agent session). Review credits: average per review
// on docs.github.com (Lite 0.25, Balanced 1.50, Max 10 USD), checked 2026-11-15. 1 AI credit = 0.01 USD.
// Run: dotnet run eng/team-credits.cs -- [developers] [business|enterprise]
using System.Globalization;

CultureInfo.CurrentCulture = CultureInfo.InvariantCulture;

int developers = args.Length > 0 ? int.Parse(args[0]) : 8;
bool enterprise = args.Length > 1 && args[1] == "enterprise";
int poolPerSeat = enterprise ? 3_900 : 1_900;
decimal seatPrice = enterprise ? 39m : 19m;
const int WorkingDays = 21;
const int SessionsPerDay = 4;
const int PullRequestsPerMonth = 12;   // per developer
const int PushesPerPullRequest = 6;    // reviews per pull request when "Review new pushes" is on
int pool = developers * poolPerSeat;

Scenario[] scenarios =
[
    new("Luna sessions, Lite review once", SessionCredits: 4, ReviewCredits: 25, ReviewsPerPullRequest: 1),
    new("Sonnet sessions, Balanced review once", 64, 150, 1),
    new("Sonnet sessions, Balanced on every push", 64, 150, PushesPerPullRequest),
    new("Opus sessions, Max on every push", 128, 1_000, PushesPerPullRequest),
];

Console.WriteLine($"{developers} developers, Copilot {(enterprise ? "Enterprise" : "Business")}: seats {developers * seatPrice:N0} USD, pool {pool:N0} AI credits per month");
Console.WriteLine($"{"Scenario",-42}{"Sessions",10}{"Reviews",10}{"Total",10}{"Pool",9}{"Extra USD",11}");
foreach (Scenario s in scenarios)
{
    long sessions = (long)s.SessionCredits * SessionsPerDay * WorkingDays * developers;
    long reviews = (long)s.ReviewCredits * s.ReviewsPerPullRequest * PullRequestsPerMonth * developers;
    long total = sessions + reviews;
    decimal extra = Math.Max(0, total - pool) / 100m;
    Console.WriteLine($"{s.Name,-42}{sessions,10:N0}{reviews,10:N0}{total,10:N0}{(decimal)total / pool,9:P0}{extra,11:N2}");
}
Console.WriteLine("GitHub Actions minutes for code review and the cloud agent are not included.");

record Scenario(string Name, int SessionCredits, int ReviewCredits, int ReviewsPerPullRequest);

$ dotnet run eng/team-credits.cs
8 developers, Copilot Business: seats 152 USD, pool 15,200 AI credits per month
Scenario                                    Sessions   Reviews     Total     Pool  Extra USD
Luna sessions, Lite review once                2,688     2,400     5,088     33 %       0.00
Sonnet sessions, Balanced review once         43,008    14,400    57,408    378 %     422.08
Sonnet sessions, Balanced on every push       43,008    86,400   129,408    851 %   1,142.08
Opus sessions, Max on every push              86,016   576,000   662,016  4,355 %   6,468.16
GitHub Actions minutes for code review and the cloud agent are not included.

The answer is on the third line: the shared pool covers only about a ninth of the month, 86,400 of the 129,408 credits come from code review, and the extra bill is around 1,142 dollars a month, more than seven times the 152 dollars for eight seats. If the same team ran the review once per pull request, the extra would drop to 422 dollars. The calculation is an estimate: the session cost rests on the thirty-step model from the first post, the review cost on the averages in the documentation, and GitHub Actions minutes are not included. But it correctly shows which settings drive the cost: the model choice and Review new pushes.

Copilot, Claude Code or Codex

This series used the same Bookstore tasks as the Claude Code and OpenAI Codex series. A short table for the decision; each tool's current price and details are in its own series:

For a team like Bookstore, with .NET and Angular code on GitHub and Visual Studio and VS Code in daily use, Copilot's strongest side is that it is already built into GitHub and the IDEs: inline suggestions, the agent, the cloud agent and code review under the same license. Teams that put long agent sessions in the terminal first should try Claude Code and Codex too; the AGENTS.md decision from the fourth post makes switching between tools possible without rewriting the instruction files.

In Production

Watch who changes policies. Against the risk of policy drift, the documentation recommends regularly reviewing who has access to policy settings and following changes in the audit log.

Set a user budget from day one. The pool belongs to the whole organization; one user's week of Max reviews or long agent sessions can use up everyone's credits.

Do not mistake content exclusion and managed settings for a security layer. Both are for GitHub's clients; the real boundary is that secrets are never in the repository or on the developer machine in the first place, plus access control and secret scanning.

Before tying preview features to a production workflow, wait for them to go GA or write a fallback plan.

Common Pitfalls

Working on company code with a personal account. Policies and the organization's content exclusion rules apply to users who get their license from the organization; someone working in the same repository on a personal plan can fall outside some of these rules. The "Block reviews requested with an external Copilot license" option in the repository settings closes that door for code review.

Writing the policy and skipping the training. If the team does not know why disableBypassPermissionsMode is on and why certain commands are denied, it will look for ways around the rules; showing the team the instruction, skill and hook files from this series matters as much as the policy.

Treating acceptance rate as productivity. A high acceptance rate can also mean suggestions accepted with Tab without reading, as in the second post.

Turning on Review new pushes by default in every repository. It is the largest item in the cost table.

Managing the MCP allowlist separately from version bumps. Because matching is exact, every version bump needs an allowlist change.

A Small Experiment

★☆☆ Run eng/team-credits.cs with your own team's numbers: developers, daily sessions, monthly pull requests and pushes. On which day of the month does the pool run out?

★★☆ Add to Bookstore's content exclusion draft the sensitive files that are git-ignored in your own repository but sit on your machine. Which belong at repository level, and which in the organization's "*" rule?

★★★ Add deny and ask rules to the managed-settings.json draft that close the shell(gh pr) gap from the ninth post (ask for approval for gh pr merge and gh pr close), and write a step in the check script that validates the syntax of these rules.

The series ends here. In ten posts we used Copilot in the same Bookstore repository, starting from plans and AI Credits and moving through inline suggestions, Chat and context, instruction files, the IDE agent, MCP, skills, custom agents and hooks, the coding agent, code review and the CLI, up to the organization level. One conclusion came up at every step: verifying what Copilot writes or approves through the diff, the tests and deterministic checks is the team's responsibility, however good the tool is. For the tool-independent practice, the AI-Assisted Development series is the next step, and for the same tasks in Claude Code and Codex, those two series.