Secrets and safe configuration

Know what is secret

Passwords, provider keys, database credentials, private keys, internal service tokens, sign in codes, and session tokens are secrets.

Server addresses, tenant names, and resource IDs may also need protection under your organisation's rules even when they are not credentials.

Store secrets only in approved fields

Use the secret field for a Connection or storage destination. Use the approved server secret store for service configuration.

The current product encrypts saved Connection and storage credentials before keeping them in the database. Settings responses do not return stored cloud credentials.

Use a limited account

Give the remote account only the network and data actions needed by the Connection. Use a separate account for each environment when possible.

Do not use a personal owner account for normal service work.

Test without exposing the value

1. Confirm the destination and sign in method.
2. Enter the secret directly into the approved field.
3. Save and test the Connection.
4. Read the result without copying the secret.
5. Test the exact workflow action with safe sample information.

Change and rotate safely

1. Name the affected Connections and services.
2. Create the new secret at its source.
3. Update the approved product setting.
4. Test the new value.
5. Remove the old value at its source.
6. Check logs and audit records for unexpected use.

If a secret is exposed

Do not paste it into a message or ask another person to confirm it. Stop or limit its use, rotate it at the source, update the product, and follow your response process.

Related tasks

Read Manage Connections, Manage settings, and Fix workflow and Connection problems.