Unable to "Get Secret" from Azure KeyVault (vault which is behind Private Endpoint)

(0) Share

Report

Posted on by ST-16031624-0

Hello!!

I’m using Power Automate Cloud Flows with VNet integration enabled (using a dedicated subnet). An Azure Key Vault is deployed in a different subnet within the same VNet and is accessed via a Private Endpoint.

Issue:

When creating a Power Automate Cloud Flow and using the Azure Key Vault connector to retrieve a secret, the flow fails with the following error:

“The dynamic invocation request failed with error: { "status": 403, "message": "Operation failed because client does not have permission to perform the operation on the key vault. Please check your permissions in the key vault access policies https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy-portal.\r\nclientRequestld: 14efda820a5f", "error": { "message": "Operation failed because client does not have permission toperform the operation on the key vault. Please check your permissions in the key vault access policies https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy-portal." l, "source":keyvault-ncus.azconn-ncus-001 .p.azurewebsites.net"

The error message appears to reference Key Vault Access Policies, which is misleading because, could be referring to old documentation from Microsoft?

The Key Vault is configured to use Azure RBAC
Required RBAC roles (e.g., Key Vault Secrets User) are already assigned to the Service Principal.

What am I missing here? Any help would be appreciated!!!

Categories:

Using flows

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Suggested answer

MParikh 521 Super User 2026 Season 1 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @ST-16031624-0,

This is a known limitation with Power Automate VNet integration and Key Vault private endpoints. The core issue is not RBAC permissions; it is a network routing problem.
Why the 403 Happens
Power Automate VNet integration uses service endpoints injected into your designated subnet to route traffic to Azure resources. When your Key Vault is behind a private endpoint with public access disabled, the service endpoint cannot "speak through" the private endpoint. The traffic still comes from a Microsoft-managed network layer and gets blocked at the Key Vault firewall level, resulting in a 403 even when RBAC roles like Key Vault Secrets User are correctly assigned.
The misleading error message about "access policies" references outdated Microsoft documentation; it does not actually mean your RBAC is wrong.
What Actually Works
Private endpoints with public access fully disabled do not work with the Power Automate Key Vault connector, even with VNet integration properly configured. Your realistic options are:

Allow Key Vault access from selected subnets only (service endpoint model). Keep public access enabled but restrict it to only your Power Platform VNet subnets. The Key Vault connector will succeed because the service endpoint is already in those subnets. This is the confirmed working pattern.

Use an Azure Function or Logic App as a proxy. Your flow calls the Azure Function, which sits inside your VNet and retrieves the secret via the private endpoint. The Function returns the secret to the flow.

Allow Microsoft trusted services. On the Key Vault networking page, enable "Allow trusted Microsoft services to bypass this firewall." This gives the Power Automate connector a path in, though it broadens access beyond just your VNet.

What to Check First
Before changing your architecture, verify these items:

On the Key Vault Networking tab, confirm your Power Platform VNet subnets are listed under "Allow access from selected virtual networks."

Confirm the enterprise policy is actually applied to your Power Platform environment and the environment shows it in the recent operations history.

DNS resolution: the Power Platform subnet must resolve the Key Vault URI to the private endpoint IP, not the public one. A missing or misconfigured private DNS zone A record breaks this.

The quickest fix with minimal rework is switching from "private endpoint + public access disabled" to "selected VNet subnets only" on the Key Vault firewall, which keeps it off the public internet while remaining compatible with the Power Automate connector.

Thank you!
Proud to be a Super User!
📩 Need more help?
✔️ Don’t forget to Accept as Solution if this guidance worked for you.
💛 Your Like motivates me to keep helping

Was this reply helpful? Yes No
ST-16031624-0 4 on at

Like
a
(0)

Report
Copy link

Link copied!

I did enable SerivceEndpoint on subnet that delegated to Powerautomate and enabled public network access to selected vnet(in my case, i allowed vnet that enabled service endpoint for keyvault) still getting 403 error that posted in my query before. and removed private endpoint..

I havent setup the enterprise policy associate to my vnet as per this documentation https://medium.com/rapha%C3%ABl-pothin/power-platforms-protection-virtual-network-integration-c2833e88e37d is this a required setup that making my connection to keyvault failed? @MParikh

Was this reply helpful? Yes No
MM-17041829-0 2 on at

Like
a
(0)

Report
Copy link

Link copied!
Hello,

this issue seems very similar to what we're dealing with the implementation of Power Platform + Power Automate + Azure Key Vault + vNets at the company I work for.
I'm a developer on the project, so I'm not getting all the subtleties of the networking aspects, while also being relatively new in the Power Automate developing scene.

@MParikh, I went through your 'What to Check First' items and found this:

- I went to our key vault > Settings > Networking:

- in the 'Firewalls and virtual networks' tab the option 'Disable public access' is disabled with the Exception 'Allow trusted Microsoft services to bypass this firewall' checked

- in the 'Private endpoint connections' tab we have one private endpoint in the list with a Sub-resource 'vault' and a Connection state 'Approved'

- I set the vNet policy on the environment, and it shows up as 'New Network Injection Policy' type in the environment's recent operations

- DNS resolution: not sure how to check for this

I'm not sure what I could do to make this work. We get a 403 error when trying to get the secret within a flow, using the Get Secret Azure Key action. The connection to the Key Vault is using the 'Default Microsoft Entra ID application for OAuth' (when I'm creating the connection it does not seem like anything is checked by Power Automate as, when I intentionally put a wrong Key vault name in the input box, the connection was still created successfully).

Appreciate any pointing in the right direction on this.

Cheers!

Was this reply helpful? Yes No