unit U4 — 4 of 4

Credential hygiene

least privilege, secret managers

Every credential your flows hold is a blast radius. The question that keeps you defensible is not whether a secret leaks, but how much it can do when it does. Least privilege shrinks that radius: a token scoped to one endpoint, an environment split so staging keys cannot touch production data, a database role that can insert but not drop. Under an SLA or a GDPR audit you have to show that a single compromised step could not have reached the whole client estate — and that is a design decision you make before the incident, not after.

Centralise secrets in a dedicated manager — Vault, AWS Secrets Manager, Doppler — rather than scattering them across Connections, .env files, and step parameters. The flow reads them through a reference resolved at runtime, so the value never lives in the exported flow JSON or the run history. This buys you one place to rotate, one audit trail of who read what, and short-lived leases instead of forever-keys. Reference the secret by path and let the manager hand out a fresh value on each run.

Where it breaks: the secret that lives in six places. Copied into a step parameter, a .env file, a Slack message, and a teammate’s laptop, it cannot be rotated without hunting down every copy — so in practice it never is. Single-source every secret behind the manager, grant read access as narrowly as the flow allows, and make the manager the one place a value ever actually exists.

worked example

Pulling a short-lived, path-scoped database token from a secret manager at runtime instead of hardcoding it.

# resolved at runtime; the value never touches the exported flow JSON
vault read -field=token secret/data/youragency/engine/crm-writer

# lease: 15m, renewable — a leaked value expires before it is useful
#   policy: crm-writer  → INSERT on leads only, no DELETE, no schema access
#   audit:  every read logged with flow id and timestamp

export CRM_TOKEN=hvs.•••redacted•••     # injected into the HTTP Request Piece

field checklist

Scope every credential to one endpoint or one role.
Split staging and production secrets so keys cannot cross.
Centralise secrets in a manager, not scattered .env files.
Prefer short-lived leases over keys that never expire.
Reference secrets by path so values stay out of exports.

common failure — One secret copied into six places

A production database password sat in a Connection, two .env files, a Slack thread, and a runbook. When a contractor rolled off, rotating it meant hunting down every copy, so it stayed unchanged for a year — a standing audit finding. Store each secret once in a manager, reference it by path everywhere, and rotation becomes a single write that every flow picks up on its next run.

check your understanding

A production database password lives in a Connection, two .env files, a Slack thread, and a runbook. Rotating it has been an open audit finding for a year. What is the fix that actually makes rotation possible?

sandbox validation

The check above confirms you followed the unit. Marking the module COMPLETED takes more: build the automation in your own engine and submit the exported flow and its run evidence, signed, to your unique validation URL. See the module page for that spec.