[go: up one dir, main page]
Changelog

Subscribe to all Changelog posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Update to seat `created_at` timestamp in the Copilot user management REST API [Public Preview]

Based on customer feedback, we have updated how the created_at timestamp works in the Copilot seat details portion of responses from the following REST API endpoints:

  • /organization/{org}/billing/copilot/seats
  • /enterprises/{enterprise}/billing/copilot/seats
  • /organization/{org}/members/{username}/copilot

The created_at timestamp now shows when a user received Copilot access, rather than when their team, enterprise team, or organization was granted access. This matches the timestamp of the seat’s corresponding seat_added event in the Audit Log.

See more

Programmatic audit log configuration and multi-endpoint streaming

Audit logs play a critical role in keeping enterprises secure and auditing enterprise activity for compliance. Since becoming generally available in January 2022, audit log streaming has been used by over 2000 enterprises to transmit audit logs to Enterprises’ preferred streaming endpoints. We are excited to announce three new features that will help you programmatically configure audit log streaming to multiple endpoints of your choosing. In doing so, we aim to empower you to select and employ tools that best support your security and compliance objectives.

Audit log steaming to a user defined HTTPS event collector

You can now enroll in a private preview that allows you to stream your audit logs to a user defined HTTPS event collector. This allows audit logs to written to any endpoint capable of accepting an HTTP post and meets our requirements for streaming GitHub audit logs. By introducing a user defined HTTPs event collector, you are empowered to stream your audit logs to the tool you feel best supports your enterprise’s needs.

Configure audit log streaming to a HTTPS Event Collector in the log streaming settings page for your Enterprise audit log

This private preview is only available to GitHub Enterprise Cloud customers. Enterprise administrators interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Let us know what you think by providing feedback on our community discussion post.

Enterprise audit logs can be streamed to two endpoints

You can participate in a public preview to stream your Enterprise’s audit log to two of GitHub’s supported streaming endpoints. You can stream your audit log to two endpoints of the same type, or you can stream to two different providers.

Log streaming settings page showing two configured streams. One to Datadog and the other to Splunk

This update allows you to use your preferred choice of tools for log storage and analysis. When managing your Enterprise, you may need to employ multiple tools to ensure compliance and maintain a strong security posture. This can involve different teams, requiring different levels of access, employing different technology to accomplish their objectives in supporting your Enterprise’s security and compliance requirements. By streaming your audit logs to two endpoints, you can employ multiple log storage and analysis tools without the need for a complex log routing architecture or dealing with increased latency.

This public preview is available to all GitHub Enterprise Cloud customers. We plan to ship this feature to GitHub Enterprise Server when this feature is released as generally available. To set up multiple streams, follow the instructions for each provider for setting up audit log streaming.

Configure audit log streaming via GitHub’s REST API

You can now configure audit log streaming via the REST API. This private beta grants access to new API endpoints for the following audit log streaming actions:

  • GET Endpoint Configuration: Retrieve the audit log streaming configuration for your Enterprise.
  • Stream Key Endpoint: Provide the customer with an audit streaming key. This key is essential for our customers to encrypt their secrets before sending them via an API call.
  • POST Endpoint: Create new audit log stream configurations.
  • PUT Endpoint: Update existing audit log stream configurations.
  • DELETE Endpoint: Delete existing audit log stream configurations.

With the introduction of these new REST API endpoints, enterprise owners can programmatically create, update, delete and list their Enterprise’s audit log streams. By allowing programmatic updates to the audit log streaming configuration, customers can automate tasks like rotating your audit log streaming secrets.

These new audit log streaming endpoints will impose a rate limit of 15 API requests per hour protect the availability of the audit log streaming service. For the time being, these endpoints are only accessible via personal access token (PAT) classic and OAuth token with admin:enterprise scope.

This feature is generally available on GitHub Enterprise Cloud (GHEC) and will be included in the release of GitHub Enterprise Server (GHES) version 3.16. To learn more, check out our documentation for the REST API endpoints for enterprise audit logs

See more

Migrate repositories with GitHub Enterprise Importer using GitHub owned blob storage – Private Preview

You can now enroll in a private preview to use GitHub-owned storage when migrating repositories to GitHub Enterprise Cloud using GitHub Enterprise Importer (GEI). This means that you no longer need to provide GEI with access to a customer-owned storage account via shared access keys to perform repository migrations. Instead, migrations can now be performed with repository archives uploaded directly to GitHub.com.

Once enrolled in the preview, repository migrations can be initiated to use GitHub-owned storage via the gh gei and gh bbs2gh command line extensions by passing in the --use-github-storage flag.

Repository migrations using the gh gei command line extension and passing in the --use-github-storage flag

If you’re interested in participating in this private preview, please reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. For additional technical details, instructions for running repository migrations with GitHub owned storage, or to provide feedback on this feature, please check out our community discussion post.

See more

Enhanced 2FA Management for Orgs and Enterprises [Public Preview]

Enterprise settings page with the selected option to enable two-factor authentication for all organizations within the enterprise. An option to enforce only secure methods of authentication is also been selected. There is a warning informing the admin that members without two-factor authentication will need to add it to re-gain access.

Enterprises now have more control over their two-factor authentication (2FA) policies for all members of their organization through an enhanced 2FA enrollment experience in GitHub.
With this update, enterprise and organization administrators can ensure that users are maintaining secure 2FA methods when accessing enterprise and org resources. Currently, GitHub defines SMS/text message as an insecure method of 2FA, and TOTP authentication applications, the GitHub Mobile app, security keys, and passkeys as secure methods. Members without a secure method of 2FA configured, or who have insecure 2FA configured, will be prompted to configure secure 2FA before being allowed to access resources.

Enterprises can enable this new 2FA policy alongside a general 2FA requirement for their members, and current enterprises with a 2FA requirement can update their 2FA settings to add this secure methods enforcement. Members who are non-compliant with the new 2FA policy will no longer be removed from organizations, lessening a historical friction around enforcing 2FA policies at an enterprise or organization level, and instead be prevented from accessing enterprise or organization resources while non-compliant.

This new policy enables enterprises to protect their resources by only allowing access for users who meet the required security standards, without compromising organization membership integrity.

Learn more about the new enterprise policy for requiring only secure methods of two-factor authentication and about how GitHub is securing developer accounts using 2FA.

See more

Accessibility improvements for security overview

New accessibility enhancements to the security overview data visuals make it easier and more inclusive for everyone to interact with and understand code security insights.

Graph showing open alerts by severity on the security overview dashboard, with enhanced accessibility

What’s new?

  • Improved visual accessibility: Enhanced color contrast and better support for users with low vision, making it easier to interpret data visuals.
  • Keyboard navigation enhancements: Full keyboard-only navigation, including a clearly visible focus indicator, for smoother interactions without a mouse.
  • Assistive technology support: Improved compatibility with screen readers for better navigation and understanding of content.

These updates are now generally available on GitHub Enterprise Cloud and will be included in GitHub Enterprise Server 3.16.

Join the discussion in the GitHub Community and read more about GitHub’s commitment to accessibility

See more

Dependabot can now perform version updates for the .NET SDK

Dependabot can now keep you up to date with the latest version of the .NET SDK by updating the global.json file in your repository. You can enable updates for the .NET SDK by adding a dotnet-sdk entry to your dependabot.yml file. At this time, Dependabot will not create security alerts for the .NET SDK, although performing regular version updates will ensure you’re always using the latest .NET SDK.

See our documentation to learn more about configuring Dependabot.

See more

Build Copilot Extensions faster with skillsets

Skillset header image

Today we’re introducing skillsets, a new lightweight way to build GitHub App-based Copilot Extensions alongside our existing agents approach. While agents offer full control over the user interaction, skillsets make it easy to integrate external tools and services into Copilot Chat by defining simple API endpoints – no AI expertise needed!

What’s new ✨

  • Let Copilot handle all AI interactions and response formatting
  • Define up to 5 skill endpoints that Copilot can call
  • Simple JSON schema configuration
  • Quick setup with minimal code

Benefits for builders ⚡️

  • Faster Development: Focus on your core functionality instead of AI interactions
  • Simple Implementation: Just define API endpoints, without managing LLM logic
  • Minimal Setup: No complex server infrastructure required, with the option to use existing APIs
  • Consistent Experience: Copilot maintains natural chat interactions automatically

Choosing your integration path 🛠

  1. Skillsets: Perfect for straightforward integrations like data retrieval and basic actions. You provide the API endpoints, and Copilot handles workloads like prompt crafting and response generation.
  2. Agents: Ideal for complex workflows needing custom logic, flexible prompt crafting, or specific LLM models. You control the entire interaction.

How it works 🏗️

End users interact with skillset-based extensions just like any other Copilot Extension. Just type @ followed by the extension name and ask in natural language. Behind the scenes, Copilot:

  • Analyzes the query to determine which skill to call
  • Structures the API request based on your JSON schema
  • Calls your endpoint to get the data
  • Formats and generates the response in chat

Architecture

architecture diagram

Requirements for extension builders

  • Access to GitHub Copilot
  • For organizational builds: Free, Team, or supported Enterprise Cloud organization types
  • Skillsets only apply to extensions built as GitHub Apps, and not VS Code chat participants

Getting started 🚀

Check out our documentation to learn how to build your first skillset.

Already built a Copilot Extension as an agent? Existing agent extensions can be converted into skillsets, but one extension cannot be both a skillset and an agent.

We want to hear your feedback!

See more

Persistent commit signature verification now in public preview

We’re excited to introduce persistent commit signature verification, a powerful new feature designed to elevate the security and reliability of your repository’s commit history.

Starting today, GitHub verifies commit signatures when they are first pushed, and once a commit’s signature is verified, it remains verified within its repository’s network. This supports organizations in maintaining a secure and accurate record of contributions without constantly rechecking the validity of every signature. You can view these persistent verifications directly on GitHub, where a quick hover over the Verified badge displays the timestamp of the original verification.

Efficient, Secure, and Transparent Verification

Previously, commit signatures were verified on demand, via a process that was not performant and had risks of previously verified signatures becoming “unverified” due to various reasons like service outages or key rotations.

Persistent commit signature verification solves these issues by validating signatures at the time of the commit and storing the verification details permanently. This also brings consistency to the commit history as git commits are immutable and they do not natively support key rotation.

Managing commit signatures can be a challenge, but persistent records ensures that verified commits remain verified over time, even if signing keys are rotated, revoked, or contributors leave the organization.

How to tell if the verification has a persistent record?

When a commit’s signature is verified upon being pushed to GitHub, the verification record is stored alongside the commit. This record is immutable, ensuring that the verified status is maintained permanently.

You can view the verification timestamp by hovering over the Verified badge on GitHub or via the GitHub REST API which now includes a verified_at field.

Learn more about commit signature verification on GitHub.

Designed for Real-World Key Rotation and Contributor Management

For organizations managing signature verification – whether GPG, SSH, or X.509 keys using S/MIME – persistent commit signature verification provides a robust way to ensure signature integrity across the board. Now, any commit with a verified status can retain that status, even when the signing key is rotated or removed.

Persistent commit signature verification is applied to new commits only. For commits pushed prior to this update, persistent records will be created upon the next verification, which happens when viewing a signed commit on GitHub anywhere the verified badge is displayed, or retrieving a signed commit via the REST API. This ensures that your repository remains secure while providing flexibility in managing your verification practices.

This approach lays the groundwork for future improvements aimed at enhancing repository integrity and authenticity of contributions within GitHub.

Key Management Caveat: Revocation and Expiration

Persistent commit signature verification ensures that verified commits retain their status indefinitely, it’s important to note this records the state of the signature at the time of the commit. If a signing key is later revoked, expired, or otherwise changed, GitHub will not re-verify previously signed commits or retroactively modify the verification status.

For organizations using S/MIME keys, this does introduce a minor change: revoked S/MIME keys will not verify new commits or those without an existing persistent record. Since git commits are immutable, persistent commit signature verification aligns with this concept by maintaining the original verification status without change. Organizations may need to manage key states directly to align with their security policies, especially in cases involving frequent key rotation or revocation.

This approach ensures that once a commit is verified, it remains trusted based on the record at the time, bringing consistency and long-term reliability to your commit history.

Moving Towards a Future with Secure and Authentic Contributions

With this launch, we’re addressing a key issue: commit verification that isn’t fragile or temporary. Teams can now implement signing key policies, without worrying about losing the verified status of past work.

Stay tuned for more updates as we continue to enhance commit verification. If you have feedback or suggestions, please let us know through our GitHub Discussions forum.

See more

The GitHub Enterprise Server 3.15 Release Candidate is available

The GitHub Enterprise Server 3.15 release candidate is here

You can now download the GitHub Enterprise Server 3.15 release candidate to try out the new features in this latest version. Version 3.15 gives customers enhanced deployment requirements and security controls. Here are a few more highlights in the 3.15 release:

  • We have updated root disk size requirements. New installations of GitHub Enterprise Server version 3.15 and upgrades to 3.15 now require a root disk size of at least 400GB. System will not boot otherwise. For more information on how to increase the root disk size in the appliance, see increasing storage capacity.

  • We have also updated minimum server specs recommended to run GHES. For more information, see minimum recommended requirements.

  • You can now interact with project status updates using GraphQL and webhooks. This unlocks new ways to automate how you provide and gather project status update information. For more information, see GitHub Projects.

  • Custom properties now support new property types: multi select and true/false. Organization repositories can now be queried and filtered via properties. Both the UI and API are supported. Read about filtering repositories.

  • Code security configurations are now available in GHES. These configurations simplify the rollout of GitHub security products at scale. They help you define collections of security settings and apply them across groups of repositories. We have retired the old organization-level code security settings UI experience along with the API parameters that complemented it. For more information, see code security configurations.

  • Secret scanning push protection is now supported for content upload REST API endpoints – create a blob and create or update file contents. Push protection blocks you from pushing secrets to a repository and generates a secret scanning alert whenever you bypass the block.

  • CodeQL‘s support for Swift and Kotlin is now generally available. CodeQL is the static analysis engine that powers GitHub code scanning.

  • Organization owners can now grant a user or team access to all of the repositories in their org with a single click. New pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them. These can be further customized as well to grant specific repository permissions across your organization. For more information, see organization roles.

Release Candidates are a way for you to try the latest features early, and they help us gather feedback to ensure the release works in your environment. They should be tested on non-production environments. Read more about the release candidate process.

To learn more about GHES 3.15, check out release notes, or download the 3.15 release candidate now.

If you have any feedback or questions about the release candidate, please contact our Support Team.

See more

Secret scanning: ability to add an optional comment when reopening alerts

To remediate and triage alerts more effectively, you can now add an optional comment when reopening a secret scanning alert. Comments will appear in the alert timeline. Previously, you could only add a comment when closing the alert.

Learn more about how to secure your repositories with secret scanning. Let us know what you think by participating in a GitHub community discussion or signing up for a 60 minute feedback session.

See more

Push protection bypass request details are included in the REST API, webhooks, and audit logs for secret scanning alerts

Secret scanning alerts resulting from an approved push protection bypass request will now show relevant details in the alert information surfaced in the REST API, webhooks, and audit logs. This allows information currently visible in the UI to be used in automated workflows.

Secret scanning alert REST API endpoints and webhook events now include the following fields:
– push_protection_bypass_request_reviewer
– push_protection_bypass_request_comment
– push_protection_bypass_request_html_url

Audit log events for push protection bypasses now include the following fields:
– push_protection_bypass_request_reviewer
– push_protection_bypass_request_reviewer_id

Learn more about secret scanning and bypass controls for push protection.

See more

Copilot content exclusion is now generally available in IDEs

We’re excited to announce that content exclusion for Copilot is now generally available for all Copilot Business and Copilot Enterprise users! This feature, previously available only in beta, allows you to control which code Copilot can access to generate suggestions. When you exclude content from Copilot:

  • Code completion will not be available in the affected files.
  • The content in affected files will not inform code completion suggestions in other files.
  • The content in affected files will not inform GitHub Copilot Chat’s responses.

How to exclude content using content exclusions for Copilot?

Enterprise, organization, and repository admins can set up exclusions through their settings, as outlined in our documentation: Excluding content from GitHub Copilot

For availability across surfaces, please check the information here: Availability of content exclusion

Enterprise admin Copilot Content Exclusions

For users previously in beta:

Previously Used Enterprise-Level Rules:

  • If you already had enterprise-level exclusion rules set up (as described in previous changelog), you won’t experience any changes. These rules will continue to function as intended.

Previously Used Organization-Level Rules:

  • If your exclusions were previously set at the organization level but not the enterprise level: Org-level rules will no longer apply enterprise-wide. They will be limited to users who are assigned Copilot seats from your org, regardless of whether enterprise-level rules are applied.

Join the discussion within GitHub Community.

See more

Upcoming changes to data retention for Events API, Atom feed, /timeline and /dashboard-feed features

Currently, you are able to query back up to 90 days worth of events from data tables you have access to when reviewing or utilizing specific events features: Events API (including push events), Atom feed, /timeline, or /dashboard-feed. On January 30th, 2025, we will be modifying the window of data retention for these features from 90 days to 30 days.

Why are we making changes?

We are making this change to help GitHub continue to scale for all our users, while continuing to provide existing customers of these features with the ability to still query and view recent important event information.

Which APIs will be impacted in this change?

The relevant APIs that will be affected are:
– /events : List public events
– /networks/{owner}/{repo}/events : List public events for a network of repositories
– /orgs/{org}/events : List public organization events
– /repos/{owner}/{repo}/events : List repository events
– /users/{username}/events : List events for the authenticated user
– /users/{username}/events/orgs/{org} : List organization events for the authenticated user
– /users/{username}/events/public : List public events for a user
– /users/{username}/received_events : List events received by the authenticated user
– /users/{username}/received_events/public : List public events received by a user
– /feeds : Get feeds

When can you expect the changes to occur?

On January 30th, 2025, we will be reducing the window that can be queried across those specified events features from 90 days to 30 days. In advance of that, we will test this change for 24 hours on December 3rd, 2024.

Additional support

As part of this change, we are adding an additional event (DiscussionEvent) as a new EventType for the Events API. This will allow you to query for an event related to Discussions that was not previously available.

We recommend leveraging a workflow that uses weekly or daily exports if you require further historical access.

Where can I learn more?

If you have concerns, comments, or feedback, please join us in this Discussion in the GitHub Community.

See more

Updated limits for GitHub App private keys and scoped tokens

GitHub Apps are now subject to a limit of 25 private keys per application and can create scoped tokens with access to more repositories. These changes support safer key management and access practices in your applications.

25 key limit for GitHub Apps

There is now a limit (25) on the number of private keys a GitHub App can have registered at one time. 99.99%+ of apps are below this limit – the ones above this limit will be unable to create more keys until they have deleted all but 24 of their keys.

Use of multiple keys for zero-downtime key rotation is encouraged. However, sharing keys among multiple parties is not recommended, which an unlimited number of keys lead developers towards. This new limit should help app developers look for safe alternatives earlier in the development lifecycle.

See our documentation on GitHub App key management for more details and best practices.

No limit on repositories for permissions-scoped tokens

In February 2024, GitHub placed a limit on the complexity of the scoped tokens that apps could request. Now, part of this limit no longer applies. Apps can now be installed on any number of repositories in an organization and request a scoped token for all those repositories. The limitation on tokens that request a subset of both permissions and tokens remains.

To learn about scoped tokens, and how they can improve the least-privilege access of your App’s tokens, see our GitHub App authentication documentation.

See more

Organizations can now enable 2FA requirement without removing non-compliant members [GA]

Enterprises can now broadly roll out two-factor authentication (2FA) to all members of their organization through an enhanced 2FA enrollment experience in GitHub. With this update, non-compliant users will no longer be removed from organizations when an organization begins enforcing 2FA.

2FA will be enforced via conditional access policies, which means members who have not yet enabled 2FA will continue to have their organization membership, but be blocked from visiting any organization resources until they enable 2FA.

This enables organizations to enable a broader 2FA enrollment without disrupting the membership status of their members who are yet to enable 2FA. This also enables members without elevated privileges to enable or disable 2FA on their accounts without losing organization membership.

Learn more about how GitHub is securing developer accounts using 2FA, and why we’re urging more organizations to join us in these efforts.

See more

Copilot Immersive update for Copilot Enterprise customers

Screenshot showing the empty state of the new Copilot immersive experience with a number of suggestions how to get started and an a message in the input that reads - Who contribute to those files - with a repository and two files selected for context.

We’ve enhanced the fullscreen Copilot chat experience on github.com/copilot with a streamlined UI and an even easier way to handle context:

  • Effortlessly see and navigate previous conversations with a new collapsible sidebar
  • Dynamically set and remove repository context to suit your workflow
  • Manage all your resources seamlessly in a unified attachment menu

These updates are available in preview for Copilot Business and Copilot Individual users. Check out the updates, and let us know what you think using the in-product feedback option.

See more

Deprecation – Dependabot no longer supports Composer v1

As of November 6, 2024, Dependabot no longer supports Composer version 1, which has reached its end-of-life. If you continue to use Composer version 1, Dependabot will be unable to create pull requests to update your dependencies. If this affects you, we recommend updating to a supported release of Composer. As of October 2024, the newest supported version of Composer is 2.8, and the long-term supported version is 2.2.

View Composer’s official documentation for more information about supported releases.

See more

EMU OIDC CAP support is now enhanced to protect web sessions [Public Preview]

If you are using GitHub Enterprise Cloud with EMU and using OpenID Connect (OIDC) SSO, this new feature, currently in public preview, will help enforce IdP-defined IP restrictions to protect all web interactions on GitHub.

Currently, when your enterprise uses OIDC-based SSO and if any of the enterprise members change their IP address, GitHub can validate their access to your enterprise and its resources using your IdP’s Conditional Access Policy (CAP). IdP CAP validations previously covered only non-interactive flows where users authenticate with a personal access token or SSH key.

With this launch, we are now extending these validations to include all interactive web flows. If you already had IdP CAP turned ON previously, you will need to explicitly opt-in into extended protection for web sessions from their enterprise’s “Authentication security” settings. If you enable IdP CAP support after today’s public preview launch, you will get the coverage across web flows by default.

When this feature is generally available, we plan to have both interactive and non-interactive flows protected by the IdP CAP validations for all customers by default and remove the additional step of requiring to opt-in.

Learn more about GitHub’s support for your IdP’s Conditional Access Policy.

See more

Notice of breaking changes for GitHub Actions

Ubuntu-latest upcoming breaking changes

We will migrate the ubuntu-latest label to ubuntu 24 starting on December 5, 2024 and ending on January 17, 2025. The ubuntu 24 image has a different set of tools and packages than ubuntu 22. We have made cuts to the list of packages so that we can maintain our SLA for free disk space. This may break your workflows if you depend on certain packages that have been removed. Please review this list to see if you are using any affected packages.

Artifacts v3 brownouts

Artifact actions v3 will be closing down by December 5, 2024. To raise awareness of the upcoming removal, we will temporarily fail jobs using v3 of actions/upload-artifact or actions/download-artifact. Builds that are scheduled to run during the brownout periods will fail. The brownouts are scheduled for the following dates and times:
– November 14, 12pm – 1pm EST
– November 21, 9am – 5pm EST

Changes to workflow validation for pull requests originating from forked repositories

Currently, you can prevent Actions workflows from automatically running on pull requests made from forked repositories. Actions evaluates whether the actor initiating the request is trusted based on the repository’s settings. Effective today, Actions will require validation of both the pull request author and the event actor to determine if a workflow should run from a pull request event originating from a forked repository. For more information on for pull request approvals, see our documentation.

New webhook rate limit

As GitHub continues to invest in availability, GitHub Actions is introducing a new webhook rate limit per repository. Each repository is now limited to 1500 triggered events every 10 seconds. For more details about the new webhook rate limit, please refer to our documentation.

Updates to the network allow list for self-hosted runners and Azure private networking

With the upcoming GA of Immutable Actions, Actions will now be stored as packages in the GitHub Container Registry. Please ensure that your self-hosted runner allow lists are updated to accommodate the network traffic. Specifically, you should allow traffic to ghcr.io and *.actions.githubusercontent.com. If you require more specific domains, you can use pkg.actions.githubusercontent.com instead of *.actions.githubusercontent.com.

This update also affects runners in all versions of GitHub Enterprise Server that use the GitHub Connect feature to download actions directly from github.com. Customers are advised to update their self-hosted runner network allow lists accordingly. For further guidance on communication between self-hosted runners and GitHub, please refer to our documentation.

Additionally, our guidance for configuring Azure private networking has been updated to account for the the addional domains. The following IP addresses have been add to the NSG template in our documentation.
– 140.82.121.33/32
– 140.82.121.34/32
– 140.82.113.33/32
– 140.82.113.34/32
– 140.82.112.33/32
– 140.82.112.34/32
– 140.82.114.33/32
– 140.82.114.34/32
– 192.30.255.164/31
– 4.237.22.32/32
– 20.217.135.1/32
– 4.225.11.196/32
– 20.26.156.211/32

See more

Copilot subscription-based network routing is now enforced

Network requests for Copilot are routed based on a user’s Copilot subscription. Requests for Copilot Individual, Copilot Business, and Copilot Enterprise users now route through different endpoints.

This change enables Copilot Business and Copilot Enterprise customers to make sure all Copilot users on their networks are accessing Copilot through their Copilot Business or Copilot Enterprise subscription, and that all Copilot user data is handled according to the terms of their Copilot Business or Copilot Enterprise agreement. In essence, customers will be able to use their network firewall to explicitly allow access to Copilot Business or Copilot Enterprise, and/or block access to Copilot Individual.

Today we enabled enforcement of the user’s subscription on the new endpoints, ensuring only Copilot Business users can connect to Copilot Business endpoints and only Copilot Enterprise users can connect to Copilot Enterprise endpoints.

Read more about subscription-based network routing here.

See more
View more changes