Step-by-step walkthrough: Threat modeling a Claw-based marketing automation workflow.

I've been helping a team migrate their marketing automation from a monolith to a set of Kubernetes-hosted microservices, all orchestrated by a central "Claw" workflow engine (built on Temporal). We realized early on that the event-driven, multi-step nature of these workflows—handling customer data, triggering external emails, and managing user consent states—opened up unique attack surfaces. A classic network perimeter scan wouldn't cut it.

I'll walk through the threat modeling session we ran, using a simplified STRIDE-per-element approach. Our goal was to map the data flow and identify mitigations before the next major feature rollout.

**Architecture Overview:**
We had four core services:
1. `claw-orchestrator` (The Temporal workflow)
2. `audience-api` (Holds PII segments)
3. `composer-api` (Generates personalized content)
4. `dispatch-service` (Calls SendGrid/Mailgun)

The critical data flow: A workflow fetches a user segment (audience-api), generates content for each user (composer-api), and batches outbound emails (dispatch-service).

**Our Threat Modeling Whiteboard Steps:**

1. **Diagram the Data Flow:** We drew the interaction, noting all trust boundaries (between services, between K8s namespaces, and to external vendors).
2. **Identify Assets:** The primary asset was the "Customer Profile" (email, name, consent status, segmentation tags). Secondary: the workflow execution history itself.
3. **Apply STRIDE per Component:**
* **Spoofing:** Could a malicious pod impersonate `audience-api`? Mitigation: Enforce mTLS between services via a service mesh (we used Linkerd). Also, K8s service accounts with bounded tokens.
* **Tampering:** Could workflow execution state or the segment data in transit be altered? Mitigation: Enable TLS everywhere. For Temporal, we reviewed workflow idempotency and used checksums for critical input data.
* **Repudiation:** Could a workflow step deny sending an email to a user? Mitigation: All external API calls (SendGrid) must log a correlation ID to our SIEM. Temporal provides built-in audit trails.
* **Information Disclosure:** Is PII leaked in logs? We found the `composer-api` was logging full profiles in debug mode. Mitigation: Stripped in production, redaction filters in Fluent Bit.
* **Denial of Service:** Could a malformed, giant segment list crash the workflow? Mitigation: Implemented pagination in the audience fetch and added circuit breakers (via Istio) on the composer service.
* **Elevation of Privilege:** Could a compromised `dispatch-service` access the entire audience database? Mitigation: It only had a service account with write-only permissions to its own outbound queue.

One key finding was the "consent check" was happening early in the workflow and not re-verified before the email was dispatched—a race condition if consent was revoked mid-execution. We modified the workflow to pass a consent token that could be validated at the dispatch step.

Here's the snippet we added to the workflow definition for that final validation:

```go
// Within the dispatch activity, before sending
func (d *Dispatcher) ValidateConsent(ctx context.Context, userID, consentToken string) error {
// Call to the independent consent service, which checks token freshness
isValid, err := d.consentClient.ValidateToken(ctx, userID, consentToken)
if err != nil || !isValid {
return temporal.NewNonRetryableError(errors.New("consent invalid or revoked"))
}
return nil
}
```

The exercise took half a day but uncovered three high-risk issues we fixed before production. The main lesson: in a distributed workflow system, you must model threats *across the entire chain of execution*, not just at individual service boundaries. Your state machine itself becomes a critical asset to protect.