Why aren’t Azure DevOps, GitHub Actions, and Fabric treated as trusted services for Key Vault?

The main issue is that these services can execute user-supplied code. Microsoft manages the underlying infrastructure, but it can’t treat every workload running there as inherently trusted, so the services generally aren’t granted unrestricted Key Vault access by default.

Network security perimeters and managed identities may help centralize the boundary and authentication model, but they don’t automatically make every Microsoft-hosted workload trusted. You still need to verify that the specific service supports the perimeter and private connectivity features you plan to use.

Fabric Managed Private Endpoints are worth considering for Fabric workloads. Pairing private connectivity with managed identities, network security controls, and a Key Vault firewall gives you much tighter access than leaving the vault broadly public.

For Azure DevOps and GitHub, self-hosted agents are usually the cleanest option. You can run them in your own network, including through container-based jobs or managed DevOps pools, and then allow private access to Key Vault without maintaining hundreds of public IP ranges.

If public Microsoft-hosted agents are unavoidable, a pipeline can temporarily add the agent’s current outbound IP to the Key Vault firewall and remove it during cleanup. It works, but it’s more fragile than private endpoints or self-hosted agents because the IP changes and cleanup can fail.