Networking

Networking in an enterprise tenant

How a Copilot Studio agent, running in Microsoft's multi-tenant service, reaches the bridge and then the bank's services in AWS when the bank's network does not allow open internet paths. Status: proposed design, 24 October 2026, not deployed. The August 2026 deployment uses public ingress throughout.

The constraint

Copilot Studio, Teams, Microsoft 365 Copilot and the Bot Framework token service run in Microsoft's shared infrastructure. The bank cannot place them in its network, and nothing in them accepts inbound connections from the bank.

The one call the bank can bring onto its own network is the custom connector call from the agent to the gateway. With Power Platform Virtual Network (VNet) support, Power Platform runs that call from a subnet the bank delegates in its own Azure virtual network. Everything after the gateway runs on infrastructure the bank controls.

Microsoft SaaS

The agent runtime, channels and sign-in. Controlled through Entra and Power Platform policy, not through network rules.

The bank's Azure landing zone

The delegated Power Platform subnet, the bridge components and Key Vault. Controlled by the bank's network policy.

The bank's AWS estate

PingFederate and the task agents. Reached from zone 2 over a private link between the two clouds.

Every hop

#	From	To	Purpose	Can be private
1	Customer's Teams or web client	Copilot Studio	Conversation	No. Microsoft SaaS.
2	Copilot Studio (Bot Framework token service)	Entra	Customer sign-in, user token for the Bridge API	No. Microsoft to Microsoft.
3	Power Platform connector runtime	Gateway	Each agent tool call, and step-up polls	Yes, with VNet support. This is the hop the design depends on.
4	Power Platform control plane	Gateway (`/openapi.json`)	Reads the connector's OpenAPI definition when the connector is created or updated	Not known to use the VNet. Remove the dependency instead.
5	Gateway	Entra token endpoint	Federated credential chain for the mirror token	Egress to Microsoft, allowed by FQDN at the firewall.
6	Gateway	Bridge	Forward the call	Yes, inside the Container Apps environment.
7	Bridge	Attestation service	Attestation and PoP	Yes, inside the environment.
8	Bridge, attestation service	Key Vault	Sign	Yes, Key Vault private endpoint.
9	Attestation service	Entra JWKS	Verify the mirror token	Egress to Microsoft, allowed by FQDN.
10	Bridge	PingFederate token and challenge endpoints	Token exchange	Yes, over the Azure to AWS link.
11	Bridge	Task agents	A2A call with the delegated token	Yes, over the Azure to AWS link.
12	PingFederate	Entra JWKS	Verify the customer's Entra token	Egress to Microsoft from AWS, allowed by FQDN.
13	Anyone resolving the federation	Bridge federation endpoints	Read entity statements	Optional. PingFederate does not fetch during a request.
14	Operators	Graph, Key Vault management, Power Platform admin	Onboarding and administration	Admin plane, outside the request path.

Hop 13: the bridge does not need to be public

The bridge sends the full trust chain in the attestation's trust_chain header, so PingFederate verifies it without fetching anything. The fetch and list endpoints only matter to parties that resolve the federation themselves. Inside one bank, all three Container Apps can be internal.

Hop 4: stop serving the connector definition

The gateway serves the connector's OpenAPI definition today, and Power Platform reads it from Microsoft's control plane. Shipping the connector in a managed solution, with the definition from source control, removes this inbound path.

Target topology

flowchart LR
  subgraph MS["Zone 1: Microsoft SaaS"]
    CS["Copilot Studio agent"]
    BF["Bot Framework token service"]
    ENTRA["Entra ID"]
  end

  subgraph AZ["Zone 2: bank Azure landing zone"]
    subgraph PPS["Delegated Power Platform subnets"]
      CR["Connector runtime<br/>containers for the<br/>bank's environment"]
    end
    DNS["Private DNS<br/>gateway host to internal IP"]
    subgraph ACA["Internal Container Apps environment"]
      GW["gateway"]
      BR["bridge"]
      AT["attestation service<br/>(own environment and subnet)"]
    end
    KV["Key Vault<br/>private endpoint"]
    FW["Hub firewall<br/>egress allow-list:<br/>Entra only (hops 5, 9)"]
  end

  subgraph AWS["Zone 3: bank AWS estate"]
    PF["PingFederate<br/>egress to Entra JWKS (hop 12)"]
    TA["Task agents"]
  end

  CS -- "3: tool call<br/>(VNet injection)" --> CR
  CR -- "HTTPS, private IP" --> GW
  CR -. "resolves" .-> DNS
  GW -- "6" --> BR
  BR -- "7" --> AT
  BR -- "8" --> KV
  AT -- "8" --> KV
  GW -- "5" --> FW
  AT -- "9" --> FW
  BR -- "10: private link" --> PF
  BR -- "11: private link" --> TA

Numbers on the arrows are the hop numbers in the table above. Zone 2 spans australiaeast and australiasoutheast. The firewall and PingFederate reach Entra ID by egress allowed by FQDN.

Zone 2 entry: from Copilot Studio to the gateway

Option A: Power Platform VNet support (recommended)

The bank delegates a subnet to Power Platform in each Azure region paired with the environment's Power Platform region. For an Australian environment that is australiaeast and australiasoutheast. The custom connector call then starts from a container with an address in that subnet, uses the VNet's DNS, and is subject to the bank's network policy.

A Managed Environment, an Azure subscription linked to the Power Platform tenant, and an enterprise policy linking the environment to the subnets.
Every connector in the environment goes out through the subnet. Calls to public services fail unless egress allows them. A dedicated environment for these agents keeps this change away from other makers.
TLS must chain to a public root CA. Power Platform does not accept a custom root CA. The gateway's private hostname needs a certificate from a public CA, even though it resolves to a private address.
No custom code in the connector. In a VNet-linked environment, custom code uses a public endpoint and cannot reach private endpoints. Our connector uses only header policies, so it is not affected, but security logic cannot move into connector code.
Connector OAuth does not use the VNet. Our connector does not use connector-level OAuth. The customer token is passed as a header.
Subnet size. Microsoft's guidance is 25 to 30 addresses for a production environment, plus 5 reserved per subnet.

With option A, the gateway has no public ingress. A caller with a stolen connection key and customer token can no longer reach it from the internet. They would have to be inside the bank's environment.

Option B: public ingress restricted to Power Platform service tags

The gateway stays public, and ingress is restricted to the published Power Platform service tag ranges for the Australian geography. This narrows callers to Power Platform, but every Power Platform tenant in the geography shares those ranges. The connection key and customer token remain the only controls that separate the bank's agents from anyone else's. Suitable for a pilot, not for production.

Option C: on-premises data gateway

Custom connectors can reach private APIs through an on-premises data gateway. We do not recommend it here: Microsoft names VNet support as the supported option for Power Platform outbound connectivity, and the bank would operate and scale the gateway cluster. It is listed so the bank can rule it out deliberately.

Inside zone 2: the bridge components

Container Apps environment. Recreate it as an internal environment on a workload profiles plan, integrated with a bank VNet. An internal environment has no public endpoint.
Separate the signing service. Internal ingress is reachable from every app in the same environment. Put the attestation service in its own environment and subnet, reachable only from the bridge.
Egress. Send all egress through the hub firewall. Allow Entra, the container registry and the AWS link. Nothing else is needed at request time.
Key Vault. Private endpoint, public network access disabled, one vault per signing service.
DNS. A private DNS zone resolves the gateway's hostname to the environment's internal address. Both regional VNets must resolve it.
Both regions. The australiasoutheast subnet needs a route to the gateway, or calls fail during a Power Platform failover.
Minimum replicas. Set at least one replica for each app, so the first call after an idle period does not wait for a cold start inside the connector's timeout.

Zone 2 to zone 3: Azure to AWS

The calls to PingFederate and the task agents start from the bridge, in the bank's Azure subnet, with an egress address and route the bank controls. That makes this an ordinary cloud-to-cloud link, not a Power Platform problem.

Option	What it is	Fits
Existing bank backbone	Azure ExpressRoute to the bank's network, then AWS Direct Connect from it.	Most likely in practice. A bank usually sends cloud-to-cloud traffic through its own hub and inspection.
Direct interconnect	ExpressRoute and Direct Connect meeting at a shared colocation provider in Sydney.	Production, if the bank has no hub path or wants one that bypasses it.
Site-to-site IPsec VPN	Azure VPN Gateway to an AWS virtual private gateway or transit gateway, with BGP.	Pilot, or as a backup path. Quick to set up, lower throughput.
Public with fixed egress	A NAT gateway gives the bridge a fixed public address, and the AWS side allows only that address, behind TLS.	Pilot only. The application-layer controls still hold, but the network control is an address allow-list.

What the bank should decide

Can Power Platform VNet support be enabled for a dedicated Managed Environment for these agents, with delegated subnets in both Australian regions? If not, option B for a pilot only.
Which Azure to AWS path these services should use: the bank's existing backbone, a direct interconnect, or a VPN for the pilot.
Which public CA issues the certificate for the gateway's private hostname.
Does the federation need to be resolvable from outside the bank? If not, all three Container Apps are internal. If it does, publish only the federation GET endpoints through a separate public front end.
Which channel ships first, since it decides whether the design can obtain a customer token at all. See the channel table.

What changes in our build

Change	Why
Ship the connector definition from source control in a managed solution	Removes the only inbound path from Microsoft's control plane.
Internal Container Apps environments on workload profiles, signing service in its own environment	No public ingress. Network separation for the signing keys.
Minimum one replica per app	No cold start inside the connector's timeout.
The gateway rate limiter keys on the platform-supplied source address and on the connection	Behind VNet injection the source is the delegated subnet, so the limiter needs a per-connection key as well as an address.
Infrastructure-as-code for the VNets, subnets, private endpoints, DNS, Container Apps and the Power Platform enterprise policy	The network is the control. Without code it cannot be reviewed or checked for drift.

Sources

Microsoft platform statements were checked on 23 and 24 October 2026.

NextMicrosoft design review