uflow
Operational security

Secrets, credentials and API keys: the other half of decision engine security

Credit policies call bureaus and APIs with sensitive credentials. How to manage them: scoped secrets, API key lifecycle, 2FA and least privilege.

Updated July 2026 · 5 min read

In short

Bureau and API credentials are kept in a secrets store and referenced by name: they live neither in the policies nor in the code. They are separated by environment, rotated without touching the flows, and integrations use their own revocable identities.

A live credit policy handles credentials worth their weight in gold: credit bureau accounts, internal API tokens, vendor keys. The guide on role segregation covers who can touch the policy; this one covers the other half — how you safeguard what the policy uses to connect to the outside world.

Written bySantiago Etchegoyen · CTO at uFlow

CTO at uFlow. Responsible for the decision engine's architecture: API integration, orchestration of credit bureaus and data sources, running models in production, and platform security.

Keep credentials out of the policy

The baseline rule: no credential is ever written inside a node. uFlow provides a secrets store where credentials are kept protected and nodes reference them by name, without exposing their value.

The benefit is twofold: the design avoids exposing the value in the flow configuration, and rotating it means changing it in a single place — not hunting down every node that copied it.

Scopes: one secret per context

Secrets have a scope — global or bound to a specific context — which lets you separate credentials by environment or by business unit.

That design cleanly solves two needs any financial institution runs into:

  • Separate environments: the testing folder uses the bureau's sandbox credentials and the production folder uses the real ones — same secret name, no changes to the policies.
  • Separate business units: each vertical or country gets its own credentials and its own cost per query.
  • Explicit exposure: using a secret in outbound integrations is enabled on purpose — sensitive values never travel by accident.

API keys for systems, with a lifecycle

Systems that execute policies through the API authenticate with their own credentials, revocable at any time, and operate with short-lived tokens that expire. The details of the authentication scheme live in the technical documentation.

A recommended practice: one identity per integrating system — each integration with its own permissions and surgical revocation if something is compromised.

People: 2FA, expiration and least privilege

For human users, the decision engine lets you enforce a second factor (with an authenticator app), configure password expiration per user and separate permissions granularly: editing is not executing, and viewing is neither of the two.

The operational recommendation: mandatory 2FA for administrators and for any user with access to policies or sensitive data, plus a periodic review confirming that each role keeps only the permissions its function actually needs.

Technical documentation

How this is implemented in the engine, step by step.

Frequently asked questions

Common questions

Who should be able to read a secret?+

No one, once it has been created: secrets are referenced, not read. Whoever configures the node uses the secret's name without seeing its value, and the value appears in neither configurations nor logs. If there is any doubt about a secret, you rotate it — you do not inspect it.

How often should we rotate API keys?+

On any suspicion of compromise, when someone with access leaves the team, and periodically according to your institution's internal policy. Revoking and regenerating takes minutes, and with one user per integrating system the impact stays contained to that integration.

Would this work for your decisioning process?

Transform your credit assessment process with the decision engine.