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.
Client and context
Inventory managed settings and memory by client
GitHub's enterprise managed settings can arrive from the server, device management, or a file. Support is property-specific. A client that reads one managed setting does not necessarily read every setting. Record the delivery source, precedence, client version, supported property, expected value, verifier, and fallback behavior for each client you deploy.
GitHub documents repository facts and user preferences as different Copilot Memory types. The features that use them also differ. Copilot Memory was in public preview on this page’s 2026-08-24 review date, so recheck its current availability and behavior before rollout. Record whether administrator policy permits Memory, whether the representative user enabled it, which billing entity owns the user preferences, which surface can use each memory type, who can review or delete it, and the current retention and validation rules. Treat memory as mutable runtime context, not as a permission or a source-controlled instruction.
GitHub added managed plugin, MCP, OpenTelemetry, and permission-mode settings to JetBrains on August 18, 2026. Use the current managed-settings reference before each rollout, then verify the applied value in one supported client. The JetBrains managed-settings pilot gives the bounded client check. The Copilot Memory policy analysis explains why user choice can have repository consequences.
Run inputs
Treat instructions, skills, MCP, and setup files as separate 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 24, 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.
A Slack or Teams channel can supply conversation context and a default repository, while a direct message uses the linked user's permissions. Work from a shared context can use the app identity. Record the app installation scope, linked account, channel-to-repository default, branch selection, shared or direct-message identity, trigger actor, steering contributors, and review rule for app-authored pull requests. Both integrations were in public preview on this page's review date, so verify the current setup and policy documentation before rollout.
The Slack repository-binding analysis shows how an omitted destination can inherit a shared default. The Teams budget analysis covers the separate meters behind a task started from a conversation.
- 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.
Copilot automations add a continuity decision. GitHub documents each automation definition as private to its creator and outside Git, although the sessions and logs it creates can be visible to repository users. Record the definition owner, departure plan, trigger source, tool permissions, billing owner, visible session evidence, and disable path. GitHub announced comment triggers on August 3, 2026, while the current concept page reviewed here did not yet list them. Keep that trigger fact tied to the dated announcement. The comment-automation ownership analysis explains the visibility gap.
Automatic Copilot review is a separate ruleset decision. GitHub no longer enables it as a side effect of Code Quality. Record the target repositories and branches, whether drafts and new pushes trigger review, the review effort, and the human approval and merge rule. The Code Quality ruleset reversal gives the dated migration states.
Measurement
Keep usage, costs, 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.
Costs and budgets
AI credits, GitHub Actions, cloud-sandbox compute, memory and storage, budget scope, alerts, stop behavior, and billing owner.
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.
GitHub's AI usage report now breaks AI credit consumption down by model and by input, output, cache-read, and cache-write tokens. That report shows where model cost accumulated. It does not explain why the context was necessary or whether the work delivered value. The impact dashboard compares modeled cost and pull-request output across adoption groups, and GitHub describes its return figures as directional. Keep both reports beside local quality, rework, review effort, and business outcome evidence. The token-report analysis and potential-ROI analysis show the interpretation limits.
One workflow can draw from more than one meter. Current GitHub documentation says Copilot automations use AI credits and GitHub Actions minutes. Cloud sandboxes have separate compute, memory, and stopped-session storage meters. Define a budget, alert, stop condition, and owner for every meter the workflow uses. Record which work is blocked when each limit is reached. The Teams cost analysis shows the two-budget case for a task started from Teams.
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, managed-setting source, supported property, MCP source, telemetry state, and fallback behavior should be present
Context and runtime inputs
Which instructions, memory, skills, tools, branch, 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 and budgets
Which population, surface, unit, window, meter, budget, stop condition, definition date, and interpretation limit apply
Session and incident evidence
Which records exist, where they go, who may read them, and which event triggers retrieval
Review and recovery ownership
Who commits a decision, verifies behavior, approves exceptions, recovers files and remote side effects, 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.
Recovery
Separate deliberation, file recovery, and system rollback
A side chat, visual plan, or canvas can help a person inspect or discuss work before execution. The interface does not prove that a person approved a change. It also does not replace repository permissions, protected-branch rules, or a durable decision record.
GitHub Copilot CLI's /rewind command can roll back the conversation alone or the conversation and Copilot's file changes. The file option leaves a file unchanged when the user edited it after Copilot. It does not reverse an external API call, a deployed resource, a comment, a notification, or another remote side effect. After a rewind, inspect the remaining diff and run the required tests before recording recovery as successful.
Record separate recovery paths for conversation state, files, repository state, remote systems, secrets, and published outputs. Assign an owner and verification evidence to each path. The side-chat analysis covers the commitment boundary. The canvas pilot guide covers approval and execution checks for a durable visual workflow. The CLI rewind guide covers selective file recovery.
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, budget-stop check, recovery check, 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: Entry point, default repository, and acting identity: Context or memory source: Meters, budgets, alerts, and stop conditions: Decision owner: Verification owner: Expected behavior: Observed behavior: Commitment or approval evidence: Recovery path for files and remote side effects: 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: Managed client setting and delivery source: expected / unexpected / not observable Entry point, repository default, and identity: expected / unexpected / not observable Memory and other runtime context: expected / unexpected / not observable Meter, budget, and stop behavior: expected / unexpected / not observable File and remote-side-effect recovery: expected / unexpected / not observable 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 control changes. Review after changes to plans, model defaults, policy sources, supported surfaces, managed-setting delivery, client versions, instructions, memory, agents, MCP, setup workflows, channel defaults, integrations, meters, budgets, metrics, session evidence, recovery behavior, 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-24. Durable guidance on intended state, scope versus surface, representative checks, owners, evidence gaps, budgets, recovery paths, and review triggers is separated here from dated product mechanics.
Recheck plan eligibility, owner roles, model policy states, preview status, policy support by surface, managed-setting support and precedence, memory behavior, instruction sources, skills and MCP, setup precedence, automation triggers, integration identity and repository binding, usage meters, budget behavior, metrics, session evidence, and recovery support before publication or a material rollout decision.
- Managing enterprise access
- Managing enterprise model availability
- Supported surfaces for Copilot policies
- Using Copilot code review
- Issue rationale, confidence, and approvals
- Copilot cloud agent and Linear
- Copilot usage metrics definitions
- Enterprise managed-settings reference
- Managed-settings deployment
- Copilot Memory
- Copilot automations
- Configuring automatic Copilot review
- Copilot cloud agent and Slack
- Copilot cloud agent and Teams
- Usage-based billing
- Cloud and local sandbox billing
- Billing reports
- Copilot impact dashboard
- Copilot CLI command reference
- GitHub App installation and repository access
- Comment-trigger announcement, August 3, 2026
- JetBrains managed-settings announcement, August 18, 2026
FAQ
GitHub Copilot enterprise-control questions
Which GitHub Copilot settings belong in an enterprise inventory?
Record the licensed population, enterprise baseline, model access, product-surface coverage, managed client state, context and runtime inputs, entry points and write authority, measurement and budgets, session evidence, recovery 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.
Does one budget cover a GitHub Copilot run?
No. A Copilot workflow can use AI credits and other metered products, such as GitHub Actions or cloud sandbox compute, memory, and storage. Record a budget, alert, stop condition, and owner for each meter the workflow uses.
When should the enterprise-controls inventory be reviewed?
Review the inventory when plans, models, policy sources, supported surfaces, managed-setting delivery, instructions, memory, agents, integrations, meters, metrics, evidence coverage, recovery behavior, or local ownership changes. Also set a dated periodic review when no known trigger occurs.