Handling PII in Agentic Workflows and Applications

A customer support ticket lands in the queue. It contains a social security number, the customer's email, and the last four digits of a credit card. An agent picks it up and sends the contents to an LLM to summarize the case. The summary gets handed to a second agent, who enriches it by calling an external CRM API. Somewhere along the way, a trace span goes to the observability backend for debugging.

By default, without an explicit redaction layer at every hop, that SSN, that email, and that partial card number travel through each of those steps in plain text. Each hop is a place where the data was disclosed to a different system. And under GDPR, HIPAA, and CCPA, each disclosure is a separate event that has to satisfy its own legal basis, encryption posture, and residency requirements.

That's not the same problem as "should our chatbot redact PII before hitting the OpenAI API?" That problem is largely solved. This one has more surface area, more moving parts, and in most implementations today, no consistent place to enforce anything.

The question this article answers is: what does PII handling actually require once a request stops being one call and becomes a chain, and where does the platform underneath the agent fit in?

Why agents break the assumptions of traditional data privacy

Privacy frameworks like GDPR were written for a world where a person deliberately queries a system. A human clicks a button, opens a record, and exports a report. Each of those actions is bounded, human-speed, and generates a detectable number of disclosure events. Compliance programs were designed around that shape: log the access, verify the legal basis, and prove it in the audit.

Agents don't behave that way. An autonomous multi-step workflow can generate dozens of disclosure events in a single execution at machine speed, with no human sitting between each hop deciding whether it should happen. The unit of compliance shifted from a request to a chain of requests, and the frameworks haven't caught up.

There's a subtler problem underneath that one. Agents are good at reasoning across sources. An agent pulling demographic data from one system, behavioral data from another, and clinical data from a third can assemble a de-anonymized record from fragments that were each, in isolation, non-identifying. Under GDPR, HIPAA, and CCPA, that reconstructed record still counts as PII, and none of those frameworks require identification to be intentional for a violation to have occurred. The agent didn't mean to. The exposure happened anyway.

So the framing that carries the rest of the article: this is not a "detect PII better" problem. Better detectors help. But the harder question is architectural. Where does PII enter the pipeline? Where does it move? Where can enforcement actually be placed, not once, but everywhere it needs to be?

What the standard AI privacy playbook already covers

There's a well-established playbook for handling PII in AI pipelines, and any team building on LLMs should already be using it. Naming what's mature is useful because it makes clear what this article is not about.

The playbook, in rough terms, comes down to five techniques that any team handling PII in AI pipelines should already have in place.

• PII detection. Pattern matching combined with Named Entity Recognition. Microsoft Presidio is the reference implementation, which is an open-source SDK that pairs regex-based recognisers for structural entities like emails, credit card numbers, IBANs, and SSNs with a spaCy NLP model for contextual entities like person names.
• Pseudonymization. Reversible tokenization. Replace the SSN with a token, keep the mapping in a secure vault, and use the token downstream. If you need the real value back for a legitimate reason, the vault gives it to you.
• Redaction. Strip PII from the payload before it reaches the LLM. Log the redacted version. Keep the original in a controlled store if the workflow needs it later.
• Encryption in transit and at rest. TLS between services, disk-level encryption on state stores, and key rotation on a schedule. Standard stuff, but load-bearing.
• Audit logs of third-party disclosure. Track exactly what was sent to OpenAI, Anthropic, or Bedrock. The model provider is a data processor under GDPR, and you have to be able to prove what you sent them.

These techniques work. They're documented, they're battle-tested, and any team handling PII in AI pipelines should already have them in place for their single-call LLM traffic. This article is not arguing that anything on that list is wrong.

Notice what all of them have in common: they operate at the request level. A single call to a model. A single retrieval from a vector store. A single write to a log. Each control fires once, at one specific boundary. That model works fine when the pipeline is a single request.

It doesn't work as-is when that single call becomes one step in a multi-hop agent workflow, where the same PII may cross service boundaries, be persisted as an intermediate state, and be consumed by downstream agents that operate under different policies than the one that first saw the data.

What changes when PII flows through a multi-step workflow

A chatbot with PII redaction handles one call at a time. An agent workflow has to enforce the same guarantees consistently across every LLM call, every tool invocation, every state persistence, every hop between agents. The problem isn't harder in kind. It's the same problem, replicated across many more surfaces.

Here's what actually happens in practice.

Figure 1: A single-agent workflow, four disclosure events. Only one of them was controlled.

The ticket enters the system. The support agent redacts obvious PII before sending the summarization request to the LLM. That's the playbook working. But the ticket itself is still stored in the durable workflow state, where it will be reloaded at the next step. The summary the LLM returns is passed to a routing agent, which needs the customer's account context to decide where to escalate, so it re-fetches the raw record. That routing agent calls an external CRM API. The trace span for that call, written to observability, includes the request payload for debugging.

Four places PII moved. The redaction step at the LLM call was correct. It also protected exactly one of those four hops.

• Intermediate state persistence is the most common gap. Workflows durably persist their state to survive crashes. It's the whole point of durable execution. But if the state contains raw PII, the state store is now a copy of that PII, subject to its own residency, encryption, and retention requirements. The convenience of "just resume where you left off after a crash" comes with a copy of everything the workflow was holding at the moment it paused.
• Tool call results carried into downstream context are the next one. When a tool returns a record, that record often becomes part of the conversation history the next agent sees. Redacting the input to a tool call doesn't do much if the output pours PII back into the context window.
• Agent-to-agent handoffs tend to pass more than they need. The default in most agent frameworks is to hand off the accumulated context, because that's easy. But if Agent B doesn't need the customer's SSN to do its job, Agent A shouldn't be sending it. Least-privilege isn't only a policy question; it's a payload question.
• Debug logs, traces, and telemetry are, in production, often the real leak path. The application developer wrote PII redaction for the LLM call. Nobody wrote it for the OpenTelemetry span exporter. The trace goes to a third-party observability vendor with a completely different data-processing agreement, or none at all.

Every one of these controls, in the standard playbook, gets implemented in application code. The redaction call sits in the agent's code, before the model call. The state store write goes through the same agent. That model (controls in application code) has one property that doesn't survive contact with a multi-agent system: it relies on every developer, at every hop, remembering to apply the right control at the right point.

Figure 2: One redaction gate is easy to enforce. Six is a bet on every developer remembering every rule at every step.

Contrast that shape with one where the enforcement point sits below the application, in the runtime. Every state read and write, every service call, every tool invocation goes through the same layer. The developer doesn't have to remember to apply the control; the runtime applies it, or the call doesn't happen.

That shift is where the platform layer earns its place. Consistent enforcement across every hop is a property of the runtime, not of any individual agent.

What a workflow-level platform actually provides

Diagrid Catalyst is a reliable and secure platform for running agentic workloads in production, with the Dapr runtime, state stores, and message brokers managed for you. What that means specifically for PII handling is that the runtime layer under the agent is a place where controls can be applied uniformly, without asking the developer to remember them at every step.

Here's how that maps to the specific gaps.

• Intermediate state protection: Dapr supports automatic client-side encryption of application state based on AES-GCM (Advanced Encryption Standard in Galois/Counter Mode), with keys of 128, 192, or 256 bits, and supports primary and secondary encryption keys to enable a key rotation strategy. The important detail is where that encryption happens: it's performed by the Dapr sidecar before data leaves the process, and the state store backend (Redis, CosmosDB, or others) stores only ciphertext. The application code doesn't call an encryption library. Every state read and write flows through the sidecar, which means the enforcement point is the same for every agent, every workflow, every hop. There's one place to configure it, and one place to audit it.
• Per-hop access scoping: Diagrid Catalyst uses two layers here, and it's worth naming them separately because they solve different things. First, every agent and MCP server gets an App ID, which is an identity backed by SPIFFE that authenticates it to the platform as itself. Second, sitting on top of that identity layer, access policies define which App IDs can invoke which workflows or activities. Authentication says, "Who is this?" Authorization says, "What are they allowed to do?" Both are enforced at the data plane by the sidecar, not by application code. An agent that isn't allowed to call a particular tool can't call it, whether or not the developer remembered to check.
• Audit and compliance evidence: This is where the verifiable execution capabilities in Dapr 1.18 come in. Workflow History Signing, when enabled, cryptographically signs workflow execution history. It uses SPIFFE-backed application identities to make the records tamper-evident and independently verifiable. For a compliance officer asking, "Which agent processed this customer's data, at what step, and can you prove it?" that's the difference between reconstructing a log after the fact and having a signed chain of custody that was recorded as the workflow ran.

Figure 3: The sidecar is where enforcement lives. The app doesn't call an encryption library, doesn't check policies, and doesn't sign history. It talks to the sidecar; the sidecar applies the controls that the platform is configured with.

• The Conversation API: The Dapr Conversation API provides a provider-agnostic abstraction over major LLM vendors like Anthropic, OpenAI, and AWS Bedrock, and it includes a PII obfuscation feature that operates on both incoming and outgoing data. The API is currently in alpha, and the PII obfuscation behavior is still being refined against real provider integrations. So today, teams pair it with Presidio in front of LLM calls for production traffic, and the Conversation API is where that control is consolidating over time. Architecturally, this is the right place for LLM-call PII enforcement to live: one gate the runtime applies, not a call every developer has to remember.
• What the platform doesn't do: Dapr does not detect PII in unstructured text. That's not a gap in the platform; that's a boundary. Detection remains the team's responsibility, using Presidio or a comparable tool for the actual identification of names, addresses, card numbers, and the rest. What the platform provides is a consistent enforcement layer where those detection outputs can be applied uniformly across every hop. Detection is one problem. Making sure the detector's decisions are applied at every place the data moves is a different problem, and it's the one a runtime is well-suited to.

There's one more thing worth being honest about. Dapr emits its own telemetry: traces, spans, logs, and those can carry the same PII that the application code is trying to redact. If the trace span records the arguments to a workflow activity, and one of those arguments is a customer record, the PII you just kept out of the LLM is now sitting in your observability backend instead. Dapr does not redact or filter telemetry content automatically, so this falls to the team implementing the workflow: something has to sit between the activity call and the exporter. That might be a span processor that strips or hashes sensitive attributes before they leave the process, a collector-side redaction rule, or at minimum a convention that sensitive arguments never get passed as span attributes in the first place. This isn't optional hardening you get to later. Span filtering, attribute redaction, and telemetry-side PII controls are first-class controls, and they need the same enforcement discipline as everything else.

Where to go next

Single-call PII controls are necessary. They are not sufficient for agent workflows. The missing piece is a runtime layer where those controls can be enforced consistently across every hop for every LLM call, tool invocation, state persistence, and even trace span. All without asking every developer to remember every rule at every step.

That's the shift. From "protect the payload of this one call" to "protect the data across the workflow, wherever it moves." Detection is a component in that story, but it's not the whole story. Consistent enforcement is.

Once PII handling is consistent within a single agent's workflow, the next question is what happens between agents. What does policy enforcement look like when different agents in the same system operate under different data-handling rules? For example, a customer-facing agent that never sees PII at all, a fulfillment agent that needs the shipping address but not the payment method, an analytics agent that only sees aggregates? That's a governance problem at the multi-agent level, and it's where the next article in this series picks up.

If you want to start putting the concepts here into practice, the Dapr University lesson on Dapr Agents walks through the runtime primitives (workflows, state, identity) that make this enforcement model work.