Repo sync

content/billing/concepts/cost-centers.md

@@ -39,7 +39,7 @@ This is separate from a cost center budget, which caps metered charges only afte
 
 ## Cost center limitations
 
-* The maximum number of active cost centers per enterprise is 500.
+* The maximum number of active cost centers per enterprise is 1,000.
 * The maximum number of resources per cost center is 25,000.
 * A maximum of 50 resources can be added to or removed from a cost center at a time.
 * Azure subscriptions can only be added to or removed from cost centers through the UI.

content/billing/how-tos/products/use-cost-centers.md

@@ -21,7 +21,7 @@ category:
 ## Creating a cost center
 
 > [!NOTE]
-> An enterprise can create up to 500 cost centers.
+> An enterprise can create up to 1,000 cost centers.
 
 Create cost centers to monitor and manage expenses for specific organizations or repositories. A single cost center can include multiple resources of any type, such as organizations, repositories, users, and enterprise teams.
 

content/billing/reference/github-license-users.md

@@ -51,7 +51,7 @@ category:
   * {% data variables.product.company_short %} counts each outside collaborator once, even if the user account has access to multiple repositories in your organization.
 * Dormant users who are a member or owner of at least one organization in the enterprise
 
-If your enterprise does not use {% data variables.product.prodname_emus %}, you will also be billed for each of the following accounts:
+If your enterprise does not use {% data variables.product.prodname_emus %} or usage-based billing, you will also be billed for each of the following accounts. Under usage-based billing, pending invitations do not consume a license. See [AUTOTITLE](/billing/concepts/enterprise-billing/usage-based-licenses).
 
 * Anyone with a pending invitation to become an organization owner or member
   * If the invited user already consumes an enterprise license, a pending organization invitation won't use an additional license—as long as the invitation is sent to their {% data variables.product.github %} username or a verified email address on their account. 

content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/submit-dependencies-automatically.md

@@ -68,10 +68,13 @@ Once enabled, automatic dependency submission jobs will run on the self-hosted r
 
 >[!NOTE] For Maven or Gradle projects that use self-hosted runners with private Maven registries, you need to modify the Maven server settings file to allow the dependency submission workflows to connect to the registries. For more information about the Maven server settings file, see [Security and Deployment Settings](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#transitive-dependencies) in the Maven documentation.
 
-For network allowlist URLs, larger runner configuration, troubleshooting details, and package ecosystem-specific information, see [AUTOTITLE](/code-security/reference/supply-chain-security/automatic-dependency-submission).
+On a restricted network, automatic dependency submission has several outbound needs. Depending on the ecosystem, a job might download the language toolchain it runs on, the tooling it uses to detect and submit dependencies (such as the Gradle dependency-submission plugin), and your project's own dependencies from your registries.
+
+Configuring access to your dependency registry covers only the last of these. Make sure the other paths are reachable too, or mirrored internally where the ecosystem supports it.
+
+For network allowlist URLs, the option to resolve the Gradle submission plugin from an internal repository, larger runner configuration, troubleshooting details, and package ecosystem-specific information, see [AUTOTITLE](/code-security/reference/supply-chain-security/automatic-dependency-submission).
 
 ## Further reading
 
-* [AUTOTITLE](/code-security/reference/supply-chain-security/automatic-dependency-submission)
 * [AUTOTITLE](/code-security/concepts/supply-chain-security/supply-chain-security)
 * [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/use-dependency-submission-api)

content/code-security/reference/supply-chain-security/automatic-dependency-submission.md

@@ -39,6 +39,13 @@ Depending on the ecosystems you use, you may need to allowlist additional URLs.
 * `https://repo.maven.apache.org`—Maven Central repository for downloading dependencies.
 * `https://api.adoptium.net`—For downloading Adoptium/Temurin JDK distributions (default distribution used by `actions/setup-java`).
 
+For Gradle projects, you also need access to the Gradle Plugin Portal, where the autosubmission action downloads the `github-dependency-graph-gradle-plugin` by default:
+
+* `https://plugins.gradle.org`—Serves the plugin marker and `maven-metadata.xml`.
+* `https://plugins-artifacts.gradle.org`—Serves the plugin's POM, module metadata, and JAR. The Gradle Plugin Portal redirects artifact downloads to this host, so allowlisting only `plugins.gradle.org` resolves the metadata and then fails when the plugin artifact is downloaded.
+
+If your runners cannot reach the Gradle Plugin Portal, or you want to avoid depending on hosts that can change over time, resolve the plugin from an internal repository you control instead. For more information, see [Gradle projects](#gradle-projects).
+
 If you use a different JDK distribution, you may also need:
 
 * `https://aka.ms` and `https://download.microsoft.com`—For Microsoft Build of OpenJDK (note: `aka.ms` is also used for .NET downloads).
@@ -89,6 +96,21 @@ If your repository's dependencies seem inaccurate, check that the timestamp of t
 
 For Gradle projects, automatic dependency submission runs a fork of the open source Gradle actions from [gradle/actions](https://github.com/gradle/actions). The fork is available at [actions/gradle-build-tools-actions](https://github.com/actions/gradle-build-tools-actions). You can view the results of the autosubmission action under your repository's **Actions** tab. Each run will be labeled "Automatic Dependency Submission (Gradle)" and its output will contain the JSON payload which the action submitted to the API.
 
+#### Resolving the submission plugin from an internal repository
+
+By default, the action downloads the `github-dependency-graph-gradle-plugin` from the Gradle Plugin Portal (`https://plugins.gradle.org`). For self-hosted runners on a restricted network, hosting the plugin in an internal repository that you control, such as a private Artifactory or Nexus instance, is more reliable than allowlisting the portal, whose hosts and CDNs can change over time. You can point the action at your internal repository with these environment variables:
+
+* `GRADLE_PLUGIN_REPOSITORY_URL`—The URL of the internal repository to resolve the plugin from.
+* `GRADLE_PLUGIN_REPOSITORY_USERNAME` and `GRADLE_PLUGIN_REPOSITORY_PASSWORD`—Credentials, if the repository requires authentication.
+
+Automatic dependency submission runs a workflow that {% data variables.product.company_short %} manages, not one you author in your repository, so you cannot add an `env:` block to it. You can set these variables on the runner, but every job scheduled on that runner, not only automatic dependency submission jobs, inherits them.
+
+If your internal repository allows anonymous read access, you only need to set `GRADLE_PLUGIN_REPOSITORY_URL` and can omit the credential variables entirely, avoiding this concern. If the repository requires authentication, use read-only credentials and a dedicated runner. For organization- or enterprise-level runners, also restrict runner-group access to only the repositories that need these credentials. See [AUTOTITLE](/actions/how-tos/manage-runners/self-hosted-runners/manage-access).
+
+Resolving the plugin from an internal repository is separate from configuring how your build resolves its own dependencies, for example an `init.gradle` file that points at an internal registry. These variables control only where the dependency-submission plugin is downloaded from.
+
+For the latest configuration details, see the [actions/gradle-build-tools-actions](https://github.com/actions/gradle-build-tools-actions) documentation.
+
 ### .NET projects
 
 The .NET autosubmission action uses the open source [component-detection](https://github.com/microsoft/component-detection/) project as the engine for its dependency detection. It supports .NET 8.x, 9.x, and 10.x. .NET autosubmission runs if the repository's `dependabot.yml` defines `nuget` as a [`package-ecosystem`](/code-security/reference/supply-chain-security/dependabot-options-reference#package-ecosystem-) or when there is a supported manifest file in the root directory of the repository. Supported manifest files include `.sln`, `.csproj`, `packages.config`, `.vbproj`, `.vcxproj`, and `.fsproj`.

content/copilot/concepts/agents/cloud-agent/about-cloud-agent.md

@@ -156,7 +156,6 @@ You can customize {% data variables.copilot.copilot_cloud_agent %} in a number o
 ### Limitations in {% data variables.copilot.copilot_cloud_agent %}'s compatibility with other features
 
 * **{% data variables.product.prodname_copilot_short %} isn't able to comply with certain rules that may be configured for your repository**. If you have configured a ruleset or branch protection rule that isn't compatible with {% data variables.copilot.copilot_cloud_agent %}, access to the agent will be blocked. For example, a rule that only allows specific commit authors can prevent {% data variables.copilot.copilot_cloud_agent %} from creating or updating pull requests. If the rule is configured using rulesets, you can add {% data variables.product.prodname_copilot_short %} as a bypass actor to enable access. See [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#granting-bypass-permissions-for-your-branch-or-tag-ruleset).
-* **{% data variables.copilot.copilot_cloud_agent %} doesn't account for content exclusions**. Content exclusions allow administrators to configure {% data variables.product.prodname_copilot_short %} to ignore certain files. When using {% data variables.copilot.copilot_cloud_agent %}, {% data variables.product.prodname_copilot_short %} will not ignore these files, and will be able to see and update them. See [AUTOTITLE](/copilot/how-tos/configure-content-exclusion/exclude-content-from-copilot).
 * **{% data variables.copilot.copilot_cloud_agent %} only works with repositories hosted on {% data variables.product.github %}**. If your repository is stored using a different code hosting platform, {% data variables.product.prodname_copilot_short %} won't be able to work on it.
 
 ## Hands-on practice

content/copilot/concepts/agents/enterprise-management.md

@@ -23,11 +23,11 @@ The AI Controls view provides a centralized platform where you can manage and mo
 
 Enterprise owners and AI managers can control how {% data variables.copilot.copilot_cloud_agent %} is adopted across the enterprise by choosing one of four policy states. This allows you to pilot adoption progressively and manage risk.
 
-If you choose the **Enabled for selected organizations** policy, you can select organizations individually or based on organization custom properties. This lets you define dynamic groups of organizations that align with your existing organizational structure—for example, by region, compliance tier, or department. You can manage this policy setting using the REST API endpoints or directly in the AI Controls page.  See [REST API endpoints for Copilot coding agent management](/rest/copilot/copilot-coding-agent-management#copilot-coding-agent-policy-states). Please note that using custom properties to enable CCA is evaluated once at the time of configuration. Organizations will not be automatically enabled or disabled for CCA if the custom property is added, removed, or modified later. 
+If you choose the **Enabled for selected organizations** policy, you can select organizations individually or based on organization custom properties. This lets you define dynamic groups of organizations that align with your existing organizational structure—for example, by region, compliance tier, or department. You can manage this policy setting using the REST API endpoints or directly in the AI Controls page.  See [REST API endpoints for Copilot coding agent management](/rest/copilot/copilot-coding-agent-management#copilot-coding-agent-policy-states). Please note that using custom properties to enable CCA is evaluated once at the time of configuration. Organizations will not be automatically enabled or disabled for CCA if the custom property is added, removed, or modified later.
 
 ## {% data variables.copilot.copilot_custom_agents %}
 
-{% data variables.copilot.copilot_custom_agents %} are specialized versions of {% data variables.copilot.copilot_cloud_agent %} that you can configure with tailored prompts, tools, and context, making them excel at specific tasks. {% data variables.copilot.custom_agents_caps_short %} can be defined and managed at the enterprise level for greater control and compliance, or at the organization and repository levels to allow teams the flexibility to build for their specific needs. 
+{% data variables.copilot.copilot_custom_agents %} are specialized versions of {% data variables.copilot.copilot_cloud_agent %} that you can configure with tailored prompts, tools, and context, making them excel at specific tasks. {% data variables.copilot.custom_agents_caps_short %} can be defined and managed at the enterprise level for greater control and compliance, or at the organization and repository levels to allow teams the flexibility to build for their specific needs.
 
 You can manage your enterprise-level {% data variables.copilot.custom_agents_short %}:
 * From the AI Controls view
@@ -74,6 +74,12 @@ Private MCP registries apply to {% data variables.copilot.copilot_cli_short %} a
 
 For more information, see [AUTOTITLE](/copilot/concepts/mcp-management).
 
+## Enterprise-managed settings
+
+The `{% data variables.copilot.managed_setting_file %}` file allows enterprises to control how users can interact with agents across {% data variables.product.prodname_copilot_short %} clients. For example: which plugins can people install, and can people use "allow all" commands that let agents run commands without asking for permission? This file can be hosted on {% data variables.product.company_short %} or installed directly on users' machines.
+
+For more information, see [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings).
+
 ## Agent mode in the IDE
 
 Enterprise and organization owners can separately control whether their users have access to agent mode in IDE chat, independently from the "Chat in IDE" policy. This gives you finer-grained control over agentic capabilities in your developers' IDEs.

content/copilot/concepts/billing/usage-based-billing-for-organizations-and-enterprises.md

@@ -64,6 +64,9 @@ When your pooled {% data variables.product.prodname_ai_credits_short %} are exha
 * **Additional usage allowed**: Usage continues at published per-credit rates. The additional spend is charged to your organization or enterprise.
 * **Additional usage not allowed**: Usage is blocked until the next billing cycle when monthly amounts are refreshed.
 
+> [!NOTE]
+> Additional usage is **enabled by default** for organizations and enterprises. If you want to prevent any spending beyond your included {% data variables.product.prodname_ai_credits_short %}, an administrator must explicitly disable the **{% data variables.product.prodname_ai_credits_short %} paid usage** policy in your enterprise's or organization's AI Controls settings.
+
 If you have set a user-level budget and a user exhausts it, that user's access to {% data variables.product.prodname_copilot_short %} is halted, regardless of whether the organization's pool still has capacity. A user can also be blocked by an enterprise spending limit before they reach their individual user-level budget, if the spending limit runs out first. There is no automatic fallback to lower-cost models when a budget is exhausted. For more information about how these controls interact, see [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing).
 
 Additional usage budgets are set in US dollars, and usage is shown in {% data variables.product.prodname_ai_credits_short %}. {% data variables.product.prodname_ai_credits_short %} draw down the budget at a fixed rate: 1 {% data variables.product.prodname_ai_credit_singular %} = {% data variables.product.prodname_ai_credits_value %}, so a $10 USD budget covers 1,000 AI credits.

content/copilot/concepts/context/repository-indexing.md

@@ -51,6 +51,8 @@ Once an index has been created for a repository, it can be used by:
 
 {% data variables.product.prodname_copilot_short %} in {% data variables.product.prodname_vscode %} can use semantic indexing for workspace files from repositories hosted outside {% data variables.product.github %}, such as GitLab and local repositories. This feature uploads your data to {% data variables.product.github %} to make it searchable.
 
+> [!NOTE] This feature is only available on {% data variables.product.prodname_dotcom_the_website %}. It is not available on {% data variables.product.prodname_ghe_server %}.
+
 This feature is controlled by policy and is disabled by default. For organizations and enterprises with {% data variables.copilot.copilot_business_short %} or {% data variables.copilot.copilot_enterprise_short %}, an enterprise owner or organization owner must explicitly set the `Semantic indexing for non-GitHub repositories` policy to **Enabled** before members can use it. If the policy remains **Unconfigured**, the feature stays unavailable. See:
 
 * [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-enterprise-policies)

content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings.md

@@ -17,11 +17,12 @@ category:
 
 With enterprise managed settings, enterprise owners can centrally define and distribute configuration settings to supported clients for users on your enterprise's {% data variables.product.prodname_copilot_short %} plan, ensuring every member works within the same guardrails.
 
-Supported clients are:
+The following clients are supported, although not every client supports every property:
 
 * {% data variables.copilot.copilot_cli_short %}
 * {% data variables.product.prodname_vscode_shortname %}
 * The {% data variables.copilot.github_copilot_app %}
+* {% data variables.copilot.copilot_cloud_agent %}
 
 These settings apply enterprise-wide, with no organization-level override. For each supported key, the `{% data variables.copilot.managed_setting_file %}` value takes precedence over any file-based configuration a user sets in their client.
 
@@ -35,9 +36,9 @@ For detailed information on the available properties and syntax, see [AUTOTITLE]
 
 There are multiple ways to deploy enterprise managed settings. Use the following guidelines to choose the right method for you. For any method, pilot on a small device group before broad deployment.
 
-* **Server-managed**: Default for most enterprises and best for review workflows and audit history
-* **MDM-managed**: Best when IT teams need device-group targeting through existing MDM tooling on macOS and Windows
-* **File-based**: Available on all platforms, and useful when server-managed and MDM-managed deployment are not available, including developer environments such as containers and {% data variables.product.prodname_codespaces %}
+* **Server-managed**: Default for most enterprises and best for review workflows and audit history. Applies to all clients, including {% data variables.copilot.copilot_cloud_agent %}.
+* **MDM-managed**: Best when IT teams need device-group targeting through existing MDM tooling on macOS and Windows. Local clients only.
+* **File-based**: Available on all platforms, and useful when server-managed and MDM-managed deployment are not available, including developer environments such as containers and {% data variables.product.prodname_codespaces %}. Local clients only.
 
 There are additional considerations if you use a dedicated enterprise for {% data variables.copilot.copilot_business_short %}. See [Guidance for dedicated {% data variables.copilot.copilot_business_short %} enterprises](#guidance-for-dedicated-copilot-business-enterprises).