Start with ownership
Start with people and scopes, not features
Name the enterprise and plan, licensed and excluded populations, and the owners for enterprise, organization, team, repository, device, and integration decisions. If a person can receive a license from more than one enterprise, record which enterprise supplies the applicable license.
- Identify the enterprise, plan, and licensed population.
- Record excluded groups and realistic overlapping memberships.
- Name who may change each enterprise, organization, team, repository, device, and integration setting.
- Name a separate owner who verifies effective behavior.
Administrative scope says where a decision is configured. It does not say which product surfaces honor it.
Start with GitHub's current enterprise access documentation. For a dated example of additive team membership and migration rehearsal, read the enterprise-team model-access analysis.
Coverage
Check policy coverage by product surface
IDEs, CLI, cloud agent, third-party agents, code review, the Copilot app, and GitHub chat do not share one uniform policy envelope. GitHub publishes current policy applicability by surface, but that table does not prove effective behavior for your representative user or imply that an unsupported policy removes every similar capability.
- Name the behavior being controlled.
- Find the current GitHub policy and supported-surfaces entry.
- Record expected behavior on every surface the rollout uses.
- Test one representative account and repository on each material surface.
- Record unsupported or unknown surfaces as gaps, not “inherited.”
Access decisions
Separate the enterprise baseline from narrower access and exceptions
Record explicit enterprise-wide allow and block decisions before narrower grants. Optional or delegated access needs a named population; overlapping membership needs a representative-user check. Temporary exceptions need an owner, task and data boundary, evidence, expiry, and disable path.
GitHub's enterprise-team model targeting was in public preview at this page's review date. Its mechanics can change, so use current model-availability documentation rather than treating a preview structure as the permanent operating model. The open-weight model exception guide shows how to bound one model decision without confusing availability with local approval.
Run inputs
Treat instructions, skills, MCP, and setup files as run inputs
Repository files can shape agent and review behavior, but they do not enforce every permission. Record the instruction source and branch, skill or MCP context, setup workflow and runner, network policy, repository permissions and CODEOWNERS, and the human review and merge path as separate facts.
As reviewed on August 3, 2026, GitHub's Copilot code-review documentation said review can use repository instructions, agent instructions, skills, MCP, session logs, and a review-specific setup workflow. Check those details again before rollout. The head-branch instructions analysis covers the repository-level boundary, while the Agent Skills analysis explains why a skill still needs an owner, version, host, model, task, evidence, and deactivation decision.
For cross-repository automation, use the documentation witness workflow as a bounded example of deterministic routing, narrow write handlers, protected paths, evidence, and human review—not as a universal GitHub configuration.
Host settings remain a separate layer. The Mac fleet AI-app baseline is an adjacent endpoint-control example, not a GitHub Copilot host management standard.
Authority
Map who starts work, who steers it, and what may be written
Installation, account connection, trigger permission, steering context, issue mutation, repository writes, and human merge authority are different decisions. Instructions, rationale, guidance, or confidence can shape or route work; they do not substitute for permission enforcement.
- Who installs the integration and connects accounts?
- Who may trigger work, and who may add context after the trigger?
- Where is issue or comment context retained or copied?
- Which issue or repository mutation may occur?
- Which permission enforces write authority?
- Who reviews and merges or rejects the output?
Use the issue-intent automation analysis to separate rationale, confidence routing, and write permission. Use the Linear trigger and steering guide to inspect installation, trigger actors, issue context, steering contributors, and pull-request review before enabling an integration.
Measurement
Keep usage, delivery outcomes, and incident evidence separate
Usage
Licensed population, active users, requests, models, languages, feature activity, and code-generation activity.
Delivery
Pull requests, reviews, tests, reverts, incidents, cycle time, reviewer effort, and local quality evidence.
Session and incident
Prompts, responses, tool calls, attributions, session logs, destinations, retrieval, access, and retention evidence where available.
Every metric row needs a unit, population, included and excluded surfaces, time window, definition date, source URL, and interpretation limit. A schema-compatible field does not prove trend continuity. The Copilot app metrics analysis shows why activity and outcome evidence must stay separate.
Session records can contain code, prompts, tool arguments, credentials, or customer context. Restrict access by purpose and record availability, destination, retention evidence, and retrieval triggers without inventing vendor guarantees. The session evidence guide places the record beside the work and makes missing evidence visible.
Inventory coverage
Record ten connected control areas
Eligibility and licensed population
Who may use Copilot, under which plan and supplying enterprise
Enterprise baseline and delegated scope
Which features and models are allowed, blocked, optional, or delegated
Product-surface coverage
Which intended policy applies on each IDE, CLI, app, agent, review, chat, or integration surface
Models and exceptions
Which population may use a model, for which task and data boundary, with what expiry
Device and client state
Which client, version, endpoint policy, MCP source, and telemetry state should be present
Repository instructions and runtime
Which files, branch, tools, runner, setup workflow, network path, and reviewers shape a run
Trigger, steering, and write authority
Who starts work, adds context, changes records, reviews output, and may merge
Measurement definitions
Which population, surface, unit, window, definition date, and interpretation limit a metric represents
Session and incident evidence
Which records exist, where they go, who may read them, and which event triggers retrieval
Review and recovery ownership
Who verifies effective behavior, approves exceptions, disables access, and updates the inventory
Verify
Run one representative control path
Choose one model or feature, one repository, one person with realistic memberships, and one material product surface. Record licensed access, model or feature availability, repository instructions and skills, tools and runtime, trigger actors, write and review path, usage record, and session or audit evidence.
Classify every result as expected, unexpected, or not observable. “Not observable” remains an evidence gap; it is not a pass.
Copyable inventory
Keep intended and observed state in one plain record
The example row is constructed. Replace it with your current intended state, source of authority, representative evidence, exception, and review trigger. Do not paste sensitive code, prompts, transcripts, credentials, customer data, or production logs into a broadly shared inventory.
| Control area | Intended state | Scope | Surfaces | Effective population | Setting/source | Decision owner | Verification evidence | Exception/gap | Last verified | Review trigger/date |
|---|---|---|---|---|---|---|---|---|---|---|
| Example: Optional model access | Allowed only for trained platform team during evaluation | Enterprise + enterprise team | IDE and CLI; code-review applicability checked separately | Representative single-team and multi-team users | Current GitHub model-availability setting and team membership source | Enterprise owner | Account result plus three task evaluations | Additive membership may broaden access | YYYY-MM-DD | Model default, membership, billing, preview, or task-scope change |
GITHUB COPILOT ENTERPRISE CONTROLS INVENTORY Enterprise / account: Copilot plan: Inventory owner: Independent verifier: Review date: CONTROL ROW Control area: Intended state: Administrative scope (enterprise / organization / team / repository / integration / device): Product surfaces in use: Effective population and representative users: Setting, file, policy, or integration that supplies authority: Decision owner: Verification owner: Expected behavior: Observed behavior: Evidence location: Exception, unsupported surface, or observability gap: Last verified: Review trigger or next review date: REPRESENTATIVE VERIFICATION Model or feature: Repository: Representative user and memberships: Surface: Licensed access result: expected / unexpected / not observable Model or feature availability: expected / unexpected / not observable Repository instructions and skills: expected / unexpected / not observable Tools, MCP, runner, and network path: expected / unexpected / not observable Trigger and steering actors: expected / unexpected / not observable Write and human-review path: expected / unexpected / not observable Usage metric appearance: expected / unexpected / not observable Session or audit evidence: expected / unexpected / not observable Decision: keep / narrow / disable / fix and retest / collect evidence Decision owner:
Change control
Name the owner and the next review trigger
Name one inventory owner and one independent verifier for material policy changes. Review after changes to plans, model defaults, policy sources, supported surfaces, instruction files, agents, MCP, setup workflows, integrations, metrics, session evidence, client management, or local ownership. Also set a date when no event arrives.
Product documentation remains the authority for current mechanics. The local inventory remains the authority for your intended state, observed evidence, exceptions, and review decision.
Source boundary
Current mechanics belong in current documentation
Last reviewed against GitHub Docs: 2026-08-03. Durable guidance on intended state, scope versus surface, representative checks, owners, evidence gaps, and review triggers is separated here from dated product mechanics.
Recheck plan eligibility, owner roles, model policy states, preview status, policy support by surface, instruction sources, skills and MCP, setup precedence, issue automation, integration behavior, usage metrics, session evidence, and device support before publication or a material rollout decision.
FAQ
GitHub Copilot enterprise-control questions
Which GitHub Copilot settings belong in an enterprise inventory?
Record licensed population, the enterprise baseline, model access, product-surface coverage, device and client state, repository instructions and runtime inputs, trigger and write authority, measurement definitions, session evidence, owners, exceptions, and review triggers.
Does an enterprise policy apply to every Copilot surface?
No uniform coverage should be assumed. Administrative scope says where a decision is configured; product-surface coverage says where behavior occurs. Check GitHub's current supported-surfaces documentation and test each material surface with a representative account and repository.
Do custom instructions or confidence scores enforce permissions?
No. Instructions, issue context, guidance, and confidence can shape or route work. Enterprise policies, repository permissions, runner and network controls, protected branches, CODEOWNERS, and human merge rules enforce different boundaries.
When should the enterprise-controls inventory be reviewed?
Review it when plans, models, policy sources, supported surfaces, instruction files, agents, integrations, metrics, evidence coverage, client management, or local ownership changes. Also set a dated periodic review even when no known trigger occurs.