GitHub's expanded usage metrics API gives administrators more detailed visibility into which custom AI agent tools developers are using.

GitHub's consolidated Teams app lets developers investigate issues and generate pull requests directly from notifications, ahead of a November 16 retirement deadline for the legacy app.

The leaked records include the locations of ICE and CBP facilities, workers’ cell phone numbers, and the members of groups tied to wiretap programs, Palantir software, and xAI’s Grok chatbot.

The Microsoft AI and Azure MVP and longtime VSLive! speaker will help shape technical content and speaker lineups for the 2027 conference series.

Introduction

A key consideration when deploying Azure API Management Standard v2 or Premium v2 is that outbound networking behavior differs from the classic tiers. This applies both when customers manually rebuild an existing solution on one of these tiers and when they create a new deployment based on assumptions formed from classic-tier behavior.

In classic tiers, dedicated outbound IP addresses are available and are commonly used by backend services for source-IP allowlisting. With Standard v2 and Premium v2, customers should instead design outbound connectivity explicitly when a predictable public source IP is required. This article applies only to Standard v2 with virtual network integration and Premium v2 with either virtual network integration or virtual network injection.

The Challenge

Many backend systems still validate the source IP address of incoming traffic. Common examples include:

• Partner APIs
• Payment providers
• Legacy applications
• On-premises systems
• Third-party SaaS platforms

When designing a new APIM v2 service, or manually rebuilding a solution previously hosted on a classic tier, backend teams often ask:

“Which IP address should we allowlist?”

Unlike a classic-tier design that relies on the service’s dedicated outbound IP addresses, an APIM v2 service may require an explicit egress pattern. Virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for outbound traffic that traverses the integrated subnet.

Architecture

Before: Classic APIM

The backend allowlist contains the outbound public IP address associated with the APIM instance.

After: APIM v2 Service with NAT Gateway

The backend allowlist contains the public IP address assigned to the NAT Gateway. APIM outbound traffic uses the virtual network integration path, and the NAT Gateway provides the predictable public source IP for internet-bound connections from the associated subnet.

Configuration Steps

Prerequisite - Create an APIM v2 Service

The portal walkthrough in this article uses a Standard v2 instance configured for outbound virtual network integration.

As shown in the service overview, the dedicated public IP address information available in the classic tiers is not displayed for this APIM v2 instance.

 

Step 1 - Create a Virtual Network

Create or select the virtual network that will be used for APIM outbound virtual network integration.

 

Step 2 - Create a Dedicated APIM Subnet

Create a subnet dedicated to the APIM v2 instance. The integration subnet must meet the documented requirements for outbound virtual network integration.

Reference: Integrate an API Management instance with a virtual network for outbound connectivity

 

 

For APIM v2 outbound virtual network integration, delegate the subnet to Microsoft.Web/serverFarms.

 

 

Step 3 - Associate a Network Security Group

Associate a Network Security Group (NSG) with the APIM integration subnet. Configure the required rules according to the documented APIM networking dependencies, while also applying the outbound controls required by your environment.

Reference: APIM outbound virtual network integration requirements

Step 4 - Configure APIM Virtual Network Integration

In the Azure portal, open the API Management instance and navigate to Networking > Virtual network integration. Select the virtual network and dedicated subnet, and then save the configuration.

 

 

Virtual network integration can also be configured when creating the APIM instance.

References: Outbound virtual network integration | API Management v2 service tiers overview

Test the Current Outbound IP

This example uses a second APIM instance as the backend, although any backend service that records the request source IP can be used.

Before NAT Gateway is configured, the backend can observe different Azure source IP addresses. The Azure IP Ranges and Service Tags - Public Cloud file is available from the Microsoft Download Center: Download Azure IP Ranges and Service Tags – Public Cloud from Official Microsoft Download Center

 

Step 5 - Create a NAT Gateway

Create an Azure NAT Gateway and associate it with one or more Standard public IP addresses or a public IP prefix. The assigned public IP becomes the predictable source address used for applicable outbound connections through the integrated subnet.

For this example, the NAT Gateway uses a Standard public IP address resource.

 

Step 6 - Associate the NAT Gateway with the APIM Subnet

Open the NAT Gateway configuration and associate it with the APIM integration subnet.

 

After the association is applied, validate that the effective network configuration matches the intended routing, NSG, and outbound connectivity design.

Step 7 - Validate

Send a test request through APIM to an endpoint that returns the caller’s public IP address, or inspect the destination backend logs. Confirm that the observed source IP matches the public IP assigned to the NAT Gateway.

 

 

As expected, the source IP address observed by the backend now matches the NAT Gateway public IP address.

When to Use This Pattern

This pattern is useful when:

• Backend teams require source-IP allowlisting.
• Third-party vendors support only IP-based network controls.
• Legacy integrations cannot be changed quickly.
• A manual rebuild of a solution previously hosted on an APIM classic tier must preserve predictable outbound addressing.

Recommendations

A predictable source IP can simplify firewall integration, but it should not replace strong service-to-service authentication. Where supported, combine or replace IP-based controls with mechanisms such as:

• Mutual TLS (mTLS)
• OAuth 2.0
• Client certificates
• Managed identity
• Private endpoints and Private Link

Treat IP allowlisting as an additional network control rather than the primary authentication mechanism. Also validate capacity, resiliency, routing, DNS, NSG rules, and dependency access for the complete solution before production deployment.

Conclusion

APIM v2 services use a different outbound networking model from the classic tiers. For new deployments or manually rebuilt solutions, outbound virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for applicable outbound traffic and simplify integration with backend firewall rules.

A successful Copilot trial opens the door to a much bigger customer conversation and a bigger role for partners. Once users experience the value of AI in their daily work, partners can guide customers to extend that value across teams, workflows, and business processes while maintaining the security, governance, and cost controls needed to scale.

In my recent post, From AI curiosity to Copilot adoption in 30 Days, I introduced how Cloud Solution Provider (CSP) partners can use a guided, 25-user trial to bring Microsoft 365 Copilot Business to small and medium-sized business (SMB) customers. That initial experience creates momentum, but sustaining it requires a structured approach to adoption, governance, and expansion.

The opportunity is growing with the new Copilot, which brings Home, Code, and Autopilot together in one connected experience. Combined with a commercial model that supports subscriptions and usage-based billing, these advances create new ways for customers to move from AI assistance to delegated work and agent-powered business processes.

For partners, this expands opportunities across the customer lifecycle, from guiding adoption and securing environments to developing agents, managing AI consumption, and delivering ongoing services. The key is connecting these capabilities into a repeatable practice that evolves alongside customer needs.

Build on the momentum of Copilot in 30

The first 30 days give customers a practical foundation for working with AI. Through Copilot in 30, users explore how Microsoft 365 Copilot Business can improve everyday productivity across Outlook, Teams, Word, Excel, and PowerPoint before progressing to agents and more advanced scenarios.

The Copilot Success Planner gives partners a structured way to guide this experience. It creates personalized learning plans for the 25 trial users, along with a roadmap for the customer sponsor. The guided journey builds skills progressively. If the sponsor enables Copilot Cowork, Weeks 3 and 4 add Cowork prompts that introduce the possibilities of delegated work.

At the end of the trial, partners can use the sponsor's Day 30 value readout to identify where Copilot delivered results, which users and teams are ready to expand, and where additional capabilities could create business value.

That conversation now has a broader destination. With the new Copilot, customers can move through connected experiences:

• Home brings Chat, Copilot Cowork, and Office together, so users can ask questions, create content, and delegate more complex work.
• Code extends AI-powered solution development, so users can turn natural-language ideas into apps, dashboards, automations, and workflows.
• Autopilot introduces a persistent, proactive personal agent designed to keep work moving within organizational permissions.

Home and Code are rolling out through the Frontier program, and Autopilot is in private preview. They expand what customers can explore as their AI maturity grows, building on the foundation of everyday Copilot adoption.

For partners, the next step is to turn early success into a longer-term customer roadmap. The Microsoft 365 Copilot + Agents SMB Guided Experience (download kit) provides a ready-to-deliver, 90-minute engagement to reinforce value, explore new scenarios, and guide the transition toward broader adoption.

Continue reading here