Reusable agent skills

---
name: copilot-policy-inheritance-audit
description: Audit GitHub Copilot feature and model policy inheritance when an enterprise or organization needs to explain effective availability, delegated control, or default-policy drift. Do not change policies, seats, or user access.
metadata:
  author: Ryan VerWey
  reviewed: "2026-10-22"
---

# Copilot Policy Inheritance Audit

Explain why a Copilot feature or model is available, unavailable, or delegated at each managed scope. This is a read-only audit. It does not authorize policy changes, preview enrollment, seat changes, or access tests with sensitive data.

## Establish the management boundary

Record the Copilot plan, enterprise, organizations, management mode, accountable owner, evidence timestamp, and affected user groups. Determine whether model control is delegated through organizations or through enterprise teams and agent apps before interpreting any lower-level state.

Keep feature and model defaults separate. A feature default can govern unconfigured generally available capabilities, including eligible client features, Copilot code review, and MCP-server policy. A model default governs eligible released models and does not select the model used for a session.

## Build the effective-policy map

For every in-scope feature or model, record:

- capability name and whether it is a feature or model
- release stage and eligibility for the applicable default
- controlling scope and management mode
- stored state, applicable default, and delegated target
- whether the state is explicit, inherited, editable, or locked
- effective result, evidence source, and evidence time
- exceptions, client requirements, billing owner, and unresolved unknowns

Treat Unconfigured, Delegate to default policy, Delegate to organizations, and Delegate to enterprise teams/apps as distinct states. A delegated or inherited policy is not proof that a particular user can access the capability; seats, the paying organization, client support, rollout status, and other restrictions can still apply.

## Resolve inheritance before judging drift

Start at the enterprise and follow the configured management path downward. Preserve explicit enable or disable decisions. Apply the relevant default only to eligible states that are actually governed by that default.

Keep preview features out of the generally available feature-default calculation. Record opt-in state separately, including any prior preview choice that persists when the capability becomes generally available. Also record provider-documented exceptions instead of forcing them into the general inheritance rule.

When API evidence is available, prefer a read endpoint that returns the stored state, parent state, and editability together. Do not infer effective access from one field or from a single administration page.

## Test the operating process

Sample recent generally available features, released models, explicit exceptions, and delegated scopes. Check whether:

- owners reviewed the number of eligible unconfigured policies before a default took effect
- every default has a named risk rationale and review date
- stricter organizations or teams have explicit decisions where needed
- changes in management mode were reviewed for lost or newly effective lower-level policy
- newly released capabilities enter an inventory and receive a documented disposition
- policy exports and dashboards agree on state, scope, and timestamp
- access questions are verified with a permitted synthetic account only when the user authorizes testing

Do not patch a policy during the audit. If a change is requested, return a separate proposal naming the target scope, previous and proposed states, affected capabilities, owner, rollback, and verification plan.

## Report

Return:

1. Scope, management mode, assumptions, and evidence time.
2. An effective-policy map for features and models.
3. Inheritance paths and provider-documented exceptions.
4. Findings ordered by unexpected access, blocked work, and auditability risk.
5. Unconfigured, delegated, stale, or conflicting decisions needing an owner.
6. Proposed changes for separate approval, each with blast radius and rollback.
7. A repeatable read-only review cadence for new releases and policy changes.

Do not claim user access from an administrative policy alone. Do not expose user activity, proprietary prompts, repositories, tokens, or customer data in audit evidence.

## Sources

Reviewed October 22, 2026. GitHub product behavior below is provider-specific; the effective-policy map, evidence requirements, and change-review method are SLOPSTACK recommendations.

- [Default Enablement of Copilot features for Copilot Business and Enterprise](https://github.blog/changelog/2026-09-24-default-enablement-of-copilot-features-for-copilot-business-and-enterprise/)
- [About default availability of Copilot features and models](https://docs.github.com/en/copilot/concepts/enterprise/default-availability)
- [Learning about new features and models](https://docs.github.com/en/copilot/concepts/enterprise/learning-about-new-features-and-models)
- [Copilot model policy API for enterprise, orgs, and teams](https://github.blog/changelog/2026-10-19-copilot-model-policy-api-for-enterprise-orgs-and-teams/)
- [REST API endpoints for enterprise AI controls](https://docs.github.com/en/enterprise-cloud@latest/rest/enterprise-admin/ai-controls)