GitHub’s new REST endpoint lets enterprise billing teams pull per-user states for multi-user budgets instead of checking every user one by one. GitHub added a REST endpoint for enterprise owners and billing managers who need to monitor multi-user budgets, including AI-credit and premium-request budgets. What it does The endpoint returns per-user budget state for a multi-user customer scoped budget. Teams can page through users, filter by a specific user, sort results, and filter by threshold percentages so they can find people who are close to a limit without building one API call per user. Who should use it Use this if your organization runs GitHub Copilot or other GitHub metered products under enterprise budgets and needs faster spend checks across many users or cost centers. How to evaluate it Confirm your account is a GitHub Enterprise Cloud enterprise owner or billing manager. Check whether the budget is a multi-user customer scoped budget. Test threshold filters against a non-critical budget before wiring alerts. Decide whether you need separate monitoring for user overrides, because the response can include an override budget ID. Limits and risks The docs state that this endpoint does not work with GitHub App user tokens, GitHub App installation tokens, or fine-grained personal access tokens. Treat the required enterprise billing credentials as sensitive, and do not put the token in client-side scripts or shared dashboards. Sources GitHub changelog: https://github.blog/changelog/2026-07-10-per-user-states-for-multi-user-budgets-in-the-rest-api/ GitHub REST API docs: https://docs.github.com/en/enterprise-cloud@latest/rest/billing/budgets?apiVersion=2026-03-10

LinkLoot access: Free
Provider costs: Unknown

Review open

@ZachasADMIN

Open loot

Use GitHub innersource advisories to push private dependency fixes inside an enterprise

No votes yet

#github #security+3

GitHub Advanced Security enterprise customers can now publish private innersource security advisories that trigger internal Dependabot alerts and fix PRs. GitHub innersource advisories are now generally available for enterprise security teams that need private vulnerability distribution inside one company. Use them when an internal package, shared service, or private fork has a flaw that should trigger Dependabot alerts and update pull requests without publishing the advisory to the public GitHub Advisory Database. The workflow is narrow and useful: create or withdraw advisories through the REST API, keep visibility scoped to the enterprise, and let Dependabot notify repositories that depend on the affected component. It is a fit for internal platforms, monorepos split into reusable packages, and regulated teams that need coordinated remediation before public disclosure. Check What to verify --- --- License Requires active GitHub Code Security or GitHub Advanced Security. Scope Advisories apply to the entire enterprise, not selected org groups. Limit Each enterprise can have up to 2,000 active innersource advisories. Automation Dependabot can create alerts and version update PRs for affected repos. Disclosure Advisory data stays private to the enterprise unless separately published. Treat this as a private remediation lane, not a replacement for public CVEs or external disclosure when customers or open-source users are affected.

LinkLoot access: Free
Provider costs: Unknown

Review open

@ZachasADMIN

Open loot

Enforce Copilot CLI guardrails from MDM before agent settings drift

No votes yet

#github #copilot+3

GitHub now lets enterprise admins push managed Copilot settings to VS Code and Copilot CLI through MDM, server-managed settings, or a locked local JSON file. GitHub's managed Copilot settings are now useful for endpoint-level governance, not just account-side policy. Enterprise admins can push the same settings into VS Code and Copilot CLI through native MDM, server-managed settings, or a root-owned local managed-settings.json file. Use this when agent policies need to follow the machine, not just the signed-in user. The practical checks are simple: decide which settings must be non-bypassable, choose the delivery channel that matches your fleet, test precedence, and confirm developers cannot override the managed tier locally. Check Why it matters --- --- MDM path Windows uses HKEYLOCALMACHINE\SOFTWARE\Policies\GitHubCopilot; macOS uses managed preferences for com.github.copilot. File ownership File-based settings must live in the expected system path and should not be user-writable. Precedence Native MDM wins over server-managed settings, which win over file-based settings. Supported keys Start with permission bypass controls, model policy, plugin lists, known marketplaces, and telemetry settings. Client coverage Confirm the target VS Code and Copilot CLI versions read the managed settings before broad rollout. This is a resource, not a hands-on review. Treat it as a deployment checklist for Copilot governance across managed developer machines.

LinkLoot access: Free
Provider costs: Unknown

Review open

@ZachasADMIN

Open loot

Blog

#enterprise

More from this topic

Find Copilot AI-credit overages before one user drains a shared budget

Use GitHub innersource advisories to push private dependency fixes inside an enterprise

Enforce Copilot CLI guardrails from MDM before agent settings drift

Related reads

GitHub adds proof-of-presence checks for high-impact actions

GitHub reopens Copilot Business signups with upfront billing

OpenAI brings workspace administration into ChatGPT Work and Codex

GitHub adds MCP allowlists for Copilot enterprise deployments