Protect configuration and sensitive event data

Flowcore stores tenant configuration and durable event history. Both need clear data classification.

Use tenant variables for non-secret configuration, tenant secrets for protected values, and Sensitive Data controls for event payload fields that require governed masking or removal.

These features solve different problems. A secret is not an event field, and a Sensitive Data mask is not a general secret store.

Separate variables from secrets

A variable is ordinary configuration that may be visible to authorized operators and workloads.

Examples include:

• Feature mode
• Public service URL
• Region name
• Non-sensitive application identifier
• Log level

A secret is a protected value whose disclosure would create security or privacy risk.

Examples include:

• Database password
• Webhook delivery secret
• Third-party API token
• Signing key
• Private service credential

Do not place a value in variables merely because it is convenient to list or edit.

Manage variables with the SDK

import {
  VariableCreateCommand,
  VariableEditCommand,
  VariableListCommand,
} from "@flowcore/sdk"
 
await adminClient.execute(
  new VariableCreateCommand({
    tenantId,
    key: "ORDERS_REGION",
    value: "eu-central",
    description: "Primary processing region for the Orders service",
  }),
)

Use descriptive uppercase keys and record ownership. Avoid using one variable key for unrelated meanings across environments.

Variable changes can alter application behavior. Review and audit production updates even when the value is not secret.

Manage secrets with the SDK

import { SecretCreateCommand } from "@flowcore/sdk"
 
await adminClient.execute(
  new SecretCreateCommand({
    tenantId,
    key: "ORDER_DELIVERY_SECRET",
    value: generatedSecret,
    description: "Authenticates managed pathway delivery to Orders",
  }),
)

Create, edit, list metadata, and delete through trusted administrative tooling. Do not echo the secret value after creation.

Restrict secret administration separately from routine variable administration where the IAM model allows it.

Keep secret values out of source control

Do not embed secrets in:

• V2 resource manifests
• Application configuration committed to Git
• Event payloads or metadata
• Container images
• Browser environment variables
• CI logs
• Support fragments or tickets

A manifest can reference the name of protected configuration, but the deployment must obtain the value from the approved secret system.

Dedicated Kubernetes installations should source Flowcore tenant credentials, licenses, and platform secrets from Kubernetes Secrets or an external secret operator, not checked-in values files.

Rotate secrets deliberately

Use overlap when the consuming protocol supports it:

1. Generate a replacement value.
2. Update the protected secret store.
3. Configure producers and consumers to accept the transition.
4. Roll out consumers using the new version.
5. Verify successful authentication.
6. Revoke the old value.
7. Record completion.

For managed pathway endpoint authentication, rotate the worker's configured header and the application verifier without creating a window where neither side agrees.

Minimize sensitive data before publishing

Flowcore Sensitive Data controls help govern protected event fields, but the strongest control is not publishing unnecessary data.

Before adding a field, ask whether consumers need the raw value for replay and business behavior. Prefer stable references, tokens, classifications, or reduced representations when possible.

Never publish passwords, bearer tokens, API keys, private signing material, or raw payment credentials.

Durable history multiplies the systems that must handle the data during query, replay, projection, backup, and incident response.

Enable Sensitive Data intentionally

Sensitive Data is disabled by default. It must be enabled at the appropriate tenant level and configured for relevant event types.

An event type can specify:

• sensitiveDataEnabled
• A sensitiveDataMask describing protected payload structure

- name: customer.email-changed.0
  description: A customer's email address changed
  sensitiveDataEnabled: true
  sensitiveDataMask:
    key: customer-contact
    schema:
      type: object
      properties:
        email:
          type: string

Validate the mask in a non-production environment with representative payloads. A malformed schema can block resource updates; an incomplete schema can leave intended fields outside the control.

Understand masked and unmasked reads

Ordinary readers should receive the masked or restricted representation defined by platform policy. Access to unmasked sensitive values requires explicit permission.

Keep that permission out of broad application, developer, and support roles.

A support tool may need event identity, type, time, and processing status without seeing the protected payload. Design the tool around that minimum view.

Monitor and audit unmasked reads. Access to sensitive history should be attributable to a user or narrowly owned service workflow.

Do not confuse masking with encryption

Masking controls what authorized API readers receive. Encryption protects data from unauthorized access to storage or transport.

Use HTTPS for transport and the platform's storage controls. Where threat models require payload opacity from the platform, assess Pathways application-side symmetric encryption or another approved design.

Application-side encryption introduces key availability, rotation, replay, and disaster-recovery responsibilities. Losing the key can make retained history unusable.

Handle GDPR and privacy requests as workflows

Privacy requirements cannot be solved by casually rewriting an event log.

Define a subject-request workflow that covers:

• Identity verification
• Event types and field paths
• Legal basis and retention exceptions
• Remove versus scramble behavior
• Flowcore removal request
• Read-model cleanup
• Search, cache, and warehouse cleanup
• Export and backup treatment
• Replay behavior after removal
• Completion verification
• Audit record

Flowcore SDK commands can request removal or scrambling for targeted event-type fields and list previous removal operations.

Use targeted Sensitive Data operations instead of broad event-type truncation when the surrounding history must remain.

Coordinate derived systems

Removing or scrambling a field in Flowcore does not automatically clean every derived system.

A complete workflow must address:

• Relational read models
• Search indexes
• Caches
• Warehouses
• Object storage
• Vector indexes
• External integrations
• Export files
• Backups according to policy

Track which projections consume each sensitive event type so the privacy workflow can reach all copies.

Prevent replay from restoring removed data

A rebuilt projection can reintroduce data if it uses an old export, backup, or ungoverned event source.

Replay tools must consume the current governed representation and understand removed-sensitive-data records. Migration code should not reconstruct a removed value from another field or external snapshot.

Test a projection rebuild after representative removal operations before relying on the procedure in production.

Keep privacy audit records without retaining the data

Record:

• Request identity and approval
• Legal or policy basis
• Tenant, event type, and field path
• Remove or scramble operation
• Affected projections and stores
• Start and completion times
• Verification result
• Residual retention obligations

Do not copy the removed plaintext value into the audit record.

Respond to accidental sensitive ingestion

If a producer publishes an unauthorized sensitive field:

1. Stop or correct the producer.
2. Identify the affected event type and time range.
3. Restrict access if exposure is ongoing.
4. Use the approved targeted removal or scrambling workflow.
5. Clean derived systems.
6. Review logs and exports for copies.
7. Determine whether incident notification is required.
8. Update contract tests and payload minimization rules.

Do not hide the issue by changing only the current TypeScript schema. Retained events and projections still contain the original field.

Monitor security-sensitive operations

Alert or audit on:

• Secret creation, updates, and deletion
• API key creation and revocation
• Sensitive Data enablement changes
• Mask updates
• Unmasked event reads
• Removal and scrambling requests
• Event truncation and deletion
• Large or unexpected historical queries
• Replays involving protected event types

Correlate administrative actions with an approved deployment, privacy case, or incident.

Return to Design Flowcore IAM access for permission and role design.