Temporal Workflow Security:
Business Logic That Lives Forever and Can Be Replayed.

The Temporal Execution Model

Temporal is a workflow orchestration platform that provides durable execution — the ability to run long-running business processes (hours, days, or longer) that survive infrastructure failures. Temporal achieves this by storing the complete event history of every workflow execution in the Temporal Server and replaying that history to reconstruct workflow state on any available worker. Workers are external processes that poll the Temporal Server for tasks and execute workflow and activity code.

This model means several things from a security perspective: workflow inputs and all intermediate state are persisted on the Temporal Server; workflows can be paused, resumed, signalled, and queried externally; activity execution is decoupled from workflow execution, with workers polling for tasks; and every external interaction with a workflow (signal, query, cancellation) goes through the Temporal API, which has its own authentication and authorisation model.

Signal Injection Attacks

Temporal signals are a mechanism for sending external events to a running workflow — for example, a payment confirmation signal to a checkout workflow, or an approval signal to a provisioning workflow. Any caller with the appropriate Temporal API permissions can send a signal to any workflow in the namespace. In many Temporal deployments, namespace-level permissions are granted broadly, and the application does not validate the source or contents of signals it receives.

An attacker with access to the Temporal API can inject signals to advance workflows through approval gates, inject malicious payloads into signal data (which is deserialised by the workflow), or send cancellation signals to disrupt in-flight business processes. Unlike HTTP request injection, signal injection is asynchronous — the workflow processes the signal during its next execution window, potentially long after the attacker's access window closes.

Workflow History as a Data Exposure Risk

Temporal stores the complete event history for every workflow execution — every input, every activity result, every signal payload, every query response. This history is accessible via the Temporal API and UI and is retained until explicitly deleted or until the namespace retention period expires. In practice, many Temporal namespaces have multi-week or indefinite retention.

Workflow history frequently contains sensitive data: customer identifiers and transaction details passed as workflow inputs, API responses stored as activity results (which may contain full API payloads), internal service responses that include PII, and debugging information added during development that was never removed. The Temporal UI, if accessible to developers without fine-grained read restrictions, becomes a window into sensitive business data across all workflow executions.

Namespace Isolation Limits

Temporal namespaces provide logical isolation between different applications or environments, similar to Kubernetes namespaces. Namespace isolation controls which workflows and task queues are visible to which workers, and namespace-level permissions control API access. However, if the Temporal Server itself is compromised, or if namespace admin credentials are obtained, all namespaces are accessible — there is no hard isolation boundary equivalent to cluster-level Kubernetes RBAC.

Temporal Cloud and self-hosted deployments differ significantly in their isolation model. In Temporal Cloud, namespaces are tenant-isolated with separate encryption and access controls. Self-hosted deployments typically run a single Temporal Server with namespace-level soft isolation — providing convenience but not the hard security boundaries some applications require.

Activity Worker Security

Activity workers are the components that execute the actual business logic in Temporal workflows — calling external APIs, interacting with databases, sending notifications. Workers poll the Temporal task queue for activity tasks and execute them locally. This means the worker process needs credentials for every external system it interacts with — database connections, API keys, cloud service credentials.

The aggregation of all these credentials in the worker process makes it a high-value target. A compromised worker — through a supply chain attack on a worker dependency, a code injection vulnerability in an activity, or a container escape — has access to every credential required for every activity it serves. Unlike a microservice that has credentials only for its own dependencies, a worker may serve activities that collectively require credentials for many downstream systems.

Securing Temporal Deployments

1. Enable mTLS for worker-to-server communication: Configure Temporal to require mTLS for all client connections. Workers, application services, and the Temporal CLI must authenticate with valid certificates, preventing unauthorised signal injection or workflow querying.
2. Implement namespace-level RBAC: Define explicit permissions for each application's service account. Workers should have task-queue-specific poll and complete permissions, not namespace-wide workflow management permissions.
3. Validate signal data at the workflow level: Treat signal payloads as untrusted input. Validate signal source (where possible), validate payload structure, and never use signal data to bypass application-level authorisation checks.
4. Encrypt sensitive workflow data using the Data Converter: Implement a custom Data Converter that encrypts workflow inputs, activity results, and signal payloads before they are stored in the workflow history. Use per-workflow encryption keys where sensitive data differentiation is needed.
5. Restrict Temporal UI access: The Temporal Web UI provides access to complete workflow histories. Restrict access to operations personnel who require it and enable audit logging for all history accesses.
6. Scope activity worker credentials with least privilege: Each activity worker should have the minimum credentials required for the activities it serves. Consider splitting workers by activity sensitivity to limit the blast radius of a single worker compromise.