Secure Workflow Design v2

Keep credentials out of Workflow source, restrict every callable surface, and test with the least privilege.

Store secrets in Connections

Connection values are protected and can vary by Environment without changing Workflow YAML.

Do not place passwords, tokens, private keys, or connection strings in Value, Sample, Expression text, Step names, script source, or App frontend code. A masked Connection field and Workflow log redaction solve different problems; use both where appropriate.

Separate Environments

Use different Connection values, API Keys, hostnames, and test data for Test and production Environments. Promote a reviewed revision rather than recreating production configuration in Workflow source.

Confirm that the Workflow and Connection use the same Cluster. A Workflow cannot use a Connection that specifies a different Cluster.

Limit invocation

  • Enable only the Workflows that should run in each Environment.
  • Assign an API Key only to required Workflows.
  • For delegated MCP access, restrict the permitted users and Workflows.
  • Grant Site and Environment permissions through the smallest suitable group scope.
  • Expose narrow HTTP or MCP schemas instead of a general administrative action.

The effective permission is an intersection of the caller, API-key, Workflow, Environment, and Site rules. A valid token alone is not authorization for every Workflow.

Bound side effects

Require stable business identifiers, validate inputs, and constrain query or mutation sizes. For agent-facing Workflows, make destructive intent explicit and return deterministic errors the agent can act on.

Do not rely on designer Debug to suppress external writes. Use test tenants or records and verify every mutation in the target system.

Protect logs and errors

Use Logging.Redact on sensitive Properties, but keep secrets out of exceptions and custom logs. Redaction does not modify runtime values or sanitize every output channel.

Return customer-safe HTTP or MCP errors. Keep detailed diagnostics in authorized Workflow logs rather than exposing credentials, internal addresses, or stack traces to callers.

Review before release

  1. Resolve validation and Connection warnings.
  2. Debug with least-privilege Test credentials.
  3. Inspect logs for unintended sensitive data.
  4. Review API-key assignments, users, allowed origins, Workflow status, and Cluster placement.
  5. Promote the verified revision through Environments in order.
  6. Invoke the published interface with its actual authorization path.

See also

See App Security Model, API Key, Connection, and Workflow Log Redaction.