Keep Critical Credentials Hidden in Power Automate Runs

It is a scene that plays out in organizations every day: a flow developer needs to call a protected API, so they drop the key into a variable, wire it up to the HTTP action, and move on. The flow runs perfectly. Later, an auditor checks the run history and finds the API key displayed in plain text. This is a serious compliance breach waiting to happen.

Power Automate logs every action input and output by default. If you retrieve a secret from Azure Key Vault and pass it to an HTTP call, the raw key appears in the history of both actions. The good news is that two relatively small configuration changes — Secure Inputs and Secure Outputs — can completely lock this down.

This article walks through a realistic scenario, shows exactly which settings to apply, and covers the common mistakes that still leave secrets exposed.

What You Will Need

The Scenario: Email Validation Without the Leak

Imagine a marketing firm that cleans its contact lists using a third-party service called VerifyFast. A Power Automate flow triggers whenever a new lead is submitted. The flow calls the VerifyFast API with a secret bearer token and passes the contact’s email address.

The token must not appear in the flow run history. If an internal user or auditor browses the logs, they should see nothing but standard execution data — no secrets.

Step 1: Store the Secret in Azure Key Vault

First, get the secret out of the flow definition and into a proper vault.

1. Open the Azure Portal and navigate to your Key Vault (create one if needed).
2. Under Objects, select Secrets and click Generate/Import.
3. Create a secret named VerifyFastApiToken. Paste the actual token as the value.
4. Leave the rest at defaults and click Create.

The vault now securely holds the value. The flow will never need to embed the token directly.

Step 2: Build the Flow (Intentionally Unsafe)

Let’s build the flow as it would normally look, so you can see where the leak happens.

1. Create an Instant cloud flow.

2. Add an Azure Key Vault — Get secret action. Select your vault and the VerifyFastApiToken secret.

3. Add an HTTP action and configure it:

   • Method: POST

   • URI: https://api.verifyfast.com/v2/verify

   • Headers:

     Name	Value
     Authorization	Bearer [Secret Value from Get secret]

   • Body:

     { "email": "lead@contoso.com" }
     

4. Save and run the flow.

If you check the run history, the Get secret action exposes the token in its output, and the HTTP action exposes it in the request headers. Exactly what we want to avoid.

Step 3: Apply the Security Settings

Now fix the leak. Each action must be told to hide its inputs and/or outputs from the logging system.

For the Get secret action:

1. Click the ... menu on the Get secret action and select Settings.
2. Under Security, toggle Secure Inputs to On.
3. Toggle Secure Outputs to On.
4. Click Done.

For the HTTP action:

1. Open its Settings.
2. Toggle Secure Inputs to On.
3. Leave Secure Outputs Off (you want the response body visible for parsing and debugging).
4. Click Done.

Step 4: Verify the Results

Re-run the flow. Now open the run history. The Get secret action shows “Content not shown due to security configuration” on both its input and output. The HTTP action hides its request payload but still displays the response JSON.

The token is completely removed from the persistent logs.

Common Mistakes and Troubleshooting

Pitfall 1: Securing the vault action but forgetting the HTTP action This is the most frequent error. The token passes through the HTTP action, and the HTTP run history records the full Authorization header. You must secure both actions for the token to stay invisible.

Pitfall 2: Over-securing outputs If you turn on Secure Outputs for the HTTP action, you can still parse the response in downstream actions (the data flows inside the engine), but the values become invisible in the debug previews and run logs. This makes troubleshooting unnecessarily difficult unless the response itself is sensitive.

Pitfall 3: Using a personal connection for Key Vault A service principal with the Key Vault Secrets User role is far safer than relying on your own credentials. If your personal account is deactivated or has overly broad permissions, the flow can break or expose more secrets than intended.

Pitfall 4: Environment Variables as secret holders Environment Variables in Power Automate are visible in solution exports and flow definitions. Never store the actual secret value in an environment variable. Instead, store the name of the secret so your flow can dynamically pick the correct vault secret for different environments (Dev, Test, Prod).

Advanced: Dynamic Vault Selection with Environment Variables

To make your flow portable across environments without editing any action:

1. Define two environment variables:
   • kv_vaultName (value: prod-keyvault)
   • kv_secretName (value: VerifyFastApiToken)
2. In the Get secret action, use expressions:
   • Vault: @variables('kv_vaultName')
   • Secret: @variables('kv_secretName')

Now the same flow definition works in Dev, Test, and Prod by simply switching the solution environment variable values.

Final Recommendation

Adding Secure Inputs and Secure Outputs to your Key Vault and HTTP actions is a two-minute configuration change that carries massive compliance weight. It belongs in every flow checklist, right next to error handling and parallel branch limits.

Make it a habit:

• Always secure the inputs and outputs of any action that touches a secret.
• Never assume the Key Vault alone hides the data.
• Review your run history after deployment to confirm the change.

References

• Matthew Devaney. Hide Passwords In Power Automate Flows (and API Keys, Secrets). September 26, 2021. https://www.matthewdevaney.com/hide-passwords-in-power-automate-flows-and-api-keys-secrets/
• Microsoft Learn: Configure secure inputs and outputs for actions in Power Automate
• Microsoft Learn: Azure Key Vault basic concepts