Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Secret Store (Secret Manager)

Overview

The Secret Store provides a secure and centralized way to manage sensitive information used by integrations and workflows, such as API keys, authentication tokens, passwords, and other confidential credentials. Instead of storing these values directly within integration configurations, users can save them in the Secret Store and reference them using a secure pointer syntax:

{{secret:SECRET_NAME}}

When an integration or flow runs, the platform automatically resolves the reference and injects the corresponding secret value at runtime. This approach eliminates the need to expose sensitive credentials in configuration files while maintaining seamless access for authorized processes.

By separating secrets from application and integration settings, the Secret Store enhances security, simplifies credential management, and supports credential rotation without requiring changes to existing configurations. Sensitive values remain protected and are not exposed in:

  • User interfaces (UI)

  • API requests and logs

  • Flow or integration configurations

  • Exported flow files

  • Version-controlled assets and shared configurations

This helps organizations maintain stronger security practices, reduce the risk of credential leakage, and ensure that sensitive information is handled securely throughout the platform.

What problem it solves

  1. Prevents hardcoded credentials

    • Users no longer need to place plain-text secrets directly in Integration fields.

  2. Reduces leakage risk

    • Sensitive values are not exposed in exported files or standard configuration views.

  3. Improves secure development practices

    • Builders can follow a safer credential management model when creating and sharing flows.

  4. Supports safer portability

    • Flows can be exported and shared without including actual secret values.

Why use Secret Store

  1. Improves security

    • Helps protect the organization from data leaks and credential exposure.

  2. Supports best practices

    • Encourages developers to separate secrets from flow configuration.

  3. Safer sharing and versioning

    • Flow exports and source-controlled artifacts contain only secret pointers, not real credentials.

  4. Simplifies credential rotation

    • Secret values can be updated without rewriting every place where the integration is used.

  5. Improves isolation

    • Secrets are scoped to the integration connection where they are created.

Core concepts

  1. Secret pointers

    • Sensitive values are referenced using this syntax:

    • '{{secret:SECRETNAME}}'

    • The pointer is what gets stored in the integration field.

    • The actual secret value is resolved only at runtime.

  2. Per-connection secret scope

    • Secrets are managed per integration connection.

    • There is no global Settings → Secret Store page.

    • A secret belongs only to the integration connection where it was created.

    • This isolation helps ensure secrets are only accessible by authorized integrations.

  3. No read-value behavior After

    • After a secret is saved, the plaintext value is never returned to the UI.

    • There is no read-value API for stored secret content.

    • The plaintext exists client-side only briefly while the user types it during create or update.

  4. Export-safe design

    • Exported flow files contain only the pointer string.

    • The actual secret value is never written into the exported JSON.

Feature goals

  1. Secure secret management

    • Provide a dedicated UI to create, update, and delete secrets within each integration connection.

  2. Standardized references

    • Support a consistent pointer format for secret usage inside Integrations.

  3. Runtime resolution

    • Resolve secrets dynamically at execution time rather than storing plaintext in flow configuration.

  4. Safe exports

    • Ensure exports contain only secret references and never raw secret values.

  5. Integration isolation

    • Restrict secret usage to the integration connection where the secret is defined.

How the Secret Store works

  1. Create and store a secret

    • Open a specific integration connection, such as:

      • REST API

      • MCP

    • Go to that connection’s Secrets panel.

    • Create a secret by entering:

      • Secret Name

      • Secret Value

    • On save:

      • The value is encrypted

      • The plaintext is not returned to the UI afterward

  2. Reference the secret

  • In integration fields that require sensitive values, enter a pointer such as:

    • '{{secret:API_KEY}}'

  • Common fields include:

    • headers

    • auth tokens

    • query parameters

    • passwords

    • other secure config inputs

  1. Validation behavior

  • The system validates whether the secret reference exists and is well-formed.

  • The field shows an error only when the reference is:

    • missing

    • malformed

  • No success confirmation is shown for a valid reference.

    • Validation is errors-only

  1. Runtime behavior

  • When the flow executes and triggers the integration:

    • The system fetches the secret value from the Secret Store

    • The pointer is resolved

    • The actual value is injected into the outbound request

  1. Export behavior

  • When the flow is exported:

    • The JSON contains the pointer string, such as '{{secret:API_KEY}}'

    • The actual secret value is never included

User workflow

  1. Manage secrets within an integration connection

    • Navigate to Integrations.

    • Open a specific integration connection.

    • Use the connection’s Secrets panel.

    • Create, update, or delete secrets from that connection.

Important: Secrets are not managed from a global Settings page. They are managed within each integration connection.

  1. Create a secret

    • Select Create Secret.

    • Enter:

      • a Secret Name as the unique identifier

      • the Secret Value

      • Save the secret.

  2. What the UI shows after save

    • After saving:

      • the UI shows the Secret Name

      • the UI shows a Last Updated timestamp

      • the secret value is not returned to the UI

    • The value is not viewable later, even in masked form.

  3. Use the secret in integration fields

    • In any field that requires confidential data, enter the pointer:

      • '{{secret:SECRETNAME}}'

    • Examples include:

      • Authorization header values

      • bearer tokens

      • API keys

      • basic auth passwords

      • secure query parameters

  4. Save and validate

    • Save the integration configuration.

    • The system flags only invalid references.

      • If valid, no positive confirmation is shown.

  5. Execute the flow

    • When the flow runs, the integration resolves the pointer and uses the real secret value securely at runtime.

UI behavior and security details

  1. What users can see

    • Users can see:

      • secret names

      • last updated timestamps

      • reference pointers entered into config fields

  2. What users cannot see

    • Users cannot retrieve:

      • the stored plaintext secret

      • a later masked display of the actual value

    • There is no API that returns the saved secret value.

  3. Plaintext handling

    • The plaintext exists only briefly on the client side while the user types it during:

      • create

      • update

  4. Encrypted storage

    • Once saved, the secret value is stored in encrypted form.

Example use cases

  1. API key in request headers

    • A REST integration needs an API key in a header.

    • Instead of entering the actual key directly, the builder uses:

      • '{{secret:API_KEY}}'

    • At runtime, the system injects the stored value into the header.

  2. Bearer token for authentication

    • An integration requires an auth token.

    • The token is stored once in the Secret Store.

    • The integration references it using a pointer instead of plain text.

  3. Password for basic authentication

    • A password is stored as a secret in the integration’s Secrets panel.

    • The password field contains only:

      • '{{secret:PASSWORD}}'

    • The value is resolved only when the integration runs.

  4. Safer promotion across environments

    • A flow is exported from one environment and imported into another.

    • The flow file contains secret pointers only, not actual credentials.

    • Destination-specific secrets can be created in the target environment.

Export and import behavior

  1. Export behavior

    • Exported JSON contains the pointer string exactly as stored.

    • Example:

      • '{{secret:SECRETNAME}}'

    • This is not a special export transformation.

    • It happens naturally because the field stores the pointer, not the secret value.

  2. Import behavior

    • When a flow is imported into another environment:

      • any referenced secrets must exist in that environment’s Secret Store for the flow to become valid

  3. Current implementations note

    • According to the JIRA description, flow-level missing-secret validation is planned but not yet implemented.

    • That means future validation is expected to flag missing destination secrets more directly.

Example from the demo

For Complete Demo refer to this document

1. Secret creation in integrations, the secrets being created from the integration area rather than as general flow variables.

2. Pointer usage

  1. The presenter copied the secret reference and pasted it into an integration field such as a password field.

  1. No value retrieval, once stored, the UI never sees that secret again.

  1. The secrets are scoped by integration, allowing the same secret name to exist in different integration scopes without collision.

PreviousFlow Versioning – Branch-Based HistoryNextUnified Persona Controls/ Global Persona Setup

Last updated

Was this helpful?