GitHub Copilot Governance and Policy Guide

GitHub Copilot Governance and Policy GuideSecurity, Code Review & Enterprise11Advanced/github-copilot/security-enterprise/governance/

Governance is usually presented as a synonym for restriction, which is why it is so often done badly. An organisation that blocks everything has not governed anything — it has made one decision, and pushed the actual usage somewhere it cannot see.

The working definition: governance is the set of decisions your organisation has made deliberately, written down, with someone accountable for each. A permissive decision made deliberately is governance. A restrictive decision nobody can explain is not.

Key takeaways

• Eleven domains, each a decision rather than a setting.
• Precedence is asymmetric — least restrictive within an enterprise, most restrictive across enterprises.
• Drift is the real failure mode, not the wrong initial choice.
• A maturity model for locating yourself honestly.
• A quarterly hour is the whole ongoing cost.

The balance

1. 1Developer productivityThe reason any of this was bought.
2. 2SecurityWhat can be reached, and by what.
3. 3ComplianceWhat the organisation must be able to demonstrate.
4. 4Operational controlCost, predictability, and who decides.

Push any one to its limit and the others collapse. Maximum security means nobody uses the tool, or uses it unobserved. Maximum productivity means no answer when somebody asks what an agent can reach. The point is not to optimise one — it is to make each trade knowingly.

The eleven domains

Each is a question. The answer can legitimately be permissive.

An organisation that has consciously answered all eleven — even permissively — has a governance model. One that has configured thirty settings without answering them has a configuration.

Deciding each domain

The eleven questions are only useful with a method for answering them. Four considerations, applied in order, resolve most of them quickly.

What goes wrong if we are permissive here? Name the concrete outcome. If you cannot — if the answer is “it feels risky” — the honest position is permissive with a review date. Vague unease produces restrictions that cost real productivity and protect against nothing anybody identified.

Is the restriction enforceable? A rule that depends on people remembering is a preference. If the only implementation is asking nicely, either find the technical control or accept it as guidance and label it as such.

Who bears the cost? Restrictions are paid by developers, daily, while the benefit accrues to the organisation abstractly. That asymmetry is not an argument against restricting things; it is an argument for knowing what you are spending.

What happens when someone needs an exception? If there is no route, people route around the control. A restriction with a working exception process is stronger than one without, because the second gets quietly defeated.

Where each decision belongs

Domains resolve at different levels, and putting a decision at the wrong level is how governance produces the two characteristic failures: bottlenecks and gaps.

Enterprise for anything where inconsistency is itself the problem, where a wrong local answer is not locally recoverable, or where the decision needs context organisations do not have — contractual commitments, regulatory scope. Client policies and the MCP baseline usually belong here.

Organization for trade-offs that are genuinely local: which models a team needs, review defaults, exclusion for their repositories, seat allocation. These are better decided by people close to the work.

Repository for the operational specifics — which branches get automatic review, what the instruction files say, effort overrides.

Individual for preferences with no organisational consequence.

Precedence decides whether any of it applies

The maturity model

The Copilot Stack’s editorial framework, not a GitHub classification. It exists because “how are we doing” needs an answer more useful than a feeling.

Governing what you cannot configure

Several things that matter have no setting, and a governance model that only covers configurable controls has left the largest risks unaddressed.

Whether people review generated code properly. No policy produces this. What helps: required human approval on the categories that matter, small pull requests, and — most of all — a culture where taking an extra hour on the authorisation change is not treated as slowness.

Whether developers paste credentials into prompts. Nothing detects it, so this is entirely a knowledge and habit problem. Secrets is the content; repeating it is the mechanism.

Whether anyone understands the limits. A developer who thinks content exclusion is absolute will behave differently from one who knows it does not cover Agent mode. That difference is training, not configuration.

Whether the configuration still reflects intent. Only a review catches this.

Exceptions

Every governance model needs a route for “this rule is wrong in my case”, because the alternative is not compliance — it is people finding another way.

Name who can grant one. A person, not a committee.

Set a duration. Exceptions without expiry become the policy. This single practice prevents most drift.

Record the reason. So the next reviewer can tell a deliberate exception from an accident.

Review them as a set. Five exceptions to the same rule mean the rule is wrong, which is a finding about the policy rather than about the requesters.

Answer quickly. An exception request that sits for three weeks has already been resolved by a workaround.

Policy drift

The failure mode that actually happens. Nobody makes a bad decision; the decisions stop matching reality.

Too many administrators. Several people can change policy, and none of them considers it their job.

Emergency changes that became permanent. A restriction loosened during an incident, never restored, and now indistinguishable from a deliberate choice.

New organisations with permissive defaults. Created for good reasons by people who do not know a policy model exists — and under the least-restrictive rule, they can widen access for their members.

Servers and agents that accumulated. Each approved individually, never reviewed as a set.

Exclusion rules nobody can justify. Kept because removing something nobody understands feels risky.

The quarterly review

An hour, and it prevents nearly all of the above.

Policy state against intention. Read the current configuration; confirm each setting corresponds to a decision somebody made.

Delegation. Who can change what, and whether that list has grown by accident since last time.

Agents, both kinds. Cloud agent state and third-party agents, on the same page, because they are governed separately and forgetting one is the standard mistake.

MCP approved against MCP configured. These diverge. Check the pairing — a server reading outside content alongside one that can act — across the whole set rather than server by server.

Exclusion rules against reasons. Anything unjustifiable is a candidate for removal.

Precedence spot-check. One multi-organisation user, verified empirically.

Audit access. Confirm at least two people can still retrieve the audit log.

Anything new. Organisations, repositories and agents added since the last review, and whether their defaults changed anything.

One question to developers. Whether any of it is getting in their way. The answer is occasionally a control that costs more than it protects.

Writing the policy down

The document that matters is short. Long governance documents are written once and read never.

One line per domain. Eleven lines, each stating the decision and who owns it.

The reason, where it is not obvious. Particularly for restrictions — “blocked because our customer agreement requires it” survives a challenge that “blocked” does not.

What is deliberately permissive. The most useful section, and the one nobody writes. Recording that MCP is broadly available because the allowlist covers the risk prevents someone tightening it later out of unexamined caution.

Where the limits are. That content exclusion does not cover Edit and Agent modes, that audit logs do not contain prompts, that public-code blocking is not a licensing determination. Stating limits in your own policy is what keeps the policy honest.

Review date and owner. A document with neither is already stale.

What governance cannot do

Worth stating, because governance documents tend toward implying more than they deliver.

It cannot make an organisation compliant with anything. No configuration of the 13 controls in this cluster produces SOC 2, ISO 27001 or GDPR compliance as an output. What it produces is evidence for your own compliance process — control configuration, audit records, vendor documentation — which a qualified legal or security professional then assesses against requirements that apply to your circumstances.

It cannot guarantee that no confidential content reaches a model. The controls are targeting controls with documented gaps.

It cannot substitute for review. Nothing in a policy makes generated code correct.

It cannot transfer accountability. Automation can be delegated; responsibility for what merged cannot.

A model that fits on a page

For an organisation starting from nothing, a defensible default:

Identity. Managed seats on Business or Enterprise, assigned on request. Models. Unrestricted unless a specific reason appears. Agents. Cloud agent enabled for selected organisations; expand on evidence. Third-party agents. Explicitly decided, separately, and written down. MCP. Policy enabled, allowlist defined in managed settings before it is needed. CLI. Decided explicitly — it is a separate client policy. Code review. Automatic review on default branches, Lite, new pushes off. Public code. Blocked, which is the Business default. Content exclusion. Narrow, with reasons and the Agent-mode caveat recorded. Metrics. Collected for licence and enablement decisions; explicitly not for individual performance review. Audit. Two people can retrieve it; retention checked against your requirement.

Eleven decisions, an afternoon, and a named owner. Everything beyond it should answer something that actually happened.

Governance as the product changes

Copilot changes faster than most things a governance model covers, and a model written once will describe a product that no longer exists.

Three habits keep it current without constant attention.

Date every claim. A policy document stating what was true in March, dated March, is honest and useful. The same document undated is misleading by the time anyone reads it.

Treat new features as unconfigured rather than absent. A capability that appears in the product is available under whatever default it shipped with. The question at each review is not only “did anything change” but “did anything appear”.

Watch for capabilities that split. The pattern that has caught organisations repeatedly is one control becoming two — the cloud agent and third-party agents, the Copilot app and the CLI. A model written when they were one thing silently covers half of what it used to.

Signals that governance is failing

Useful because they appear well before an incident and are easy to miss individually.

Nobody can answer a basic question. “Can we use MCP servers” taking a week and three people is a documentation failure, and the developer has already made a decision without you.

Exception requests are frequent and similar. The rule is wrong.

Developers describe the tool as unreliable. Frequently a configuration effect nobody explained — exclusion, a client policy, an allowlist.

The configuration surprises the person who owns it. Drift, confirmed.

Metrics get quoted without their caveats. The CLI exclusion and the five-user threshold matter, and a number circulating without them will eventually inform a decision badly.

Somebody is using a personal subscription. The clearest signal that the organisational offering is not meeting a need, or that nobody told them.

Who should be in the room

Governance decisions get made badly when the wrong people make them alone, and the failure is symmetrical.

Security alone produces a model optimised against risks they can name, with no visibility of what it costs. The result is defensible on paper and generates shadow adoption.

Engineering alone produces a model optimised for convenience, with the contractual and regulatory questions left for somebody to discover later.

Legal or compliance alone produces requirements nobody can implement, usually phrased in terms that do not map onto any available control.

The workable arrangement is one person accountable — typically engineering leadership or a platform lead — who consults the others on the domains that are theirs. Security owns the MCP and exclusion judgements. Legal owns the contractual questions. Engineering owns the cost of every restriction.

Common questions

Where do we start? Level 2, and it takes an afternoon. Write down what is enabled, why, and who owns it. That single artefact resolves more real problems than any additional configuration will.

How restrictive should we be? Exactly as restrictive as you can explain, and no more. A control whose reason you cannot state will be loosened during the first inconvenient conversation anyway.

Who owns this? One person, with a named deputy who has used the settings. Distributed ownership with no owner is the most common root cause in this lesson.

How do we know it is working? Developers can say what is enabled and where to ask; you can produce the policy state on request; nothing has drifted since the last review.

Should governance be different for AI than for other tools? Mostly no — the same questions about access, audit and accountability apply. The genuine differences are that agents can act rather than only suggest, and that the product changes faster than most, which is why the review cadence matters more here.

How do we handle a team that wants everything enabled? Ask what they are trying to do. The request is usually specific and grantable; “everything” is shorthand for “the current configuration blocked me and I do not know which part”.

What about AI governance frameworks generally? They provide structure and they do not know what a cloud agent policy state is. Use them for shape; use this cluster for the specifics.

Governance for a small organisation

Everything above scales down further than it appears to, and a twenty-person company needs a governance model too — just a much shorter one.

The eleven domains still apply; the answers are simply easier. Managed seats on Business. Models unrestricted. Cloud agent on. Third-party agents decided and written down. MCP enabled with a short allowlist. CLI available. Automatic review on the main repository. Public code blocked. One or two exclusion rules. Metrics looked at when the renewal comes round. Audit access confirmed.

That is a governance model. It fits in a paragraph, somebody owns it, and every answer was made deliberately — which is the whole definition.

What small organisations should not do is skip it because they are small. The domains that bite hardest at that scale are exactly the ones that look like overkill: MCP without an allowlist, third-party agents nobody decided about, and no named owner. All three are afternoon-scale decisions that become expensive later, and none of them require a policy function to make.

Next

Adoption for engineering teams is Academy Lesson 100 — the other half of the same job, because governance without adoption is a policy for something nobody uses.