Workflow Security and Prompt Injection

Learn how to design secure automations and reduce prompt injection risk.

When you build workflows that use LLM nodes, treat all incoming ticket text, emails, form submissions, and API payloads as untrusted input. A user can intentionally or unintentionally include instructions that try to override your prompt, exfiltrate data, or trigger actions you did not intend.

What is prompt injection?

Prompt injection is an attack where untrusted content attempts to change the behavior of the LLM. In an automation workflow, that content often comes from the same business data the workflow is trying to process, such as a support ticket, an email thread, or a webhook payload.

This means an LLM node should never assume that user-provided text is safe just because it looks like normal business content.

The lethal trifecta

One especially risky pattern is what Simon Willison calls the lethal trifecta:

1. Untrusted input is passed to an LLM.

2. The LLM has access to tools or private data.

3. The LLM can take actions automatically.

If you combine all three in one step, prompt injection can become a real security issue rather than just a bad answer.

Common automation risks

Workflows become much riskier when an LLM node can do more than analyze text. Typical examples include:

• Reading sensitive data from integrated systems that the end user should not influence access to.

• Sending emails, replies, or internal notes based directly on untrusted content.

• Updating ticket fields, statuses, ownership, or permissions automatically.

• Calling write-capable tools in external systems without a deterministic validation step.

• Combining retrieval, decision-making, and write actions inside one LLM node.

Recommended design patterns

Use these patterns to reduce risk when designing workflows:

• Give LLM nodes access only to the tools they strictly need for the task.

• Prefer read-only tools over write-capable tools whenever possible.

• Separate analysis from action. Let the LLM classify, extract, summarize, or propose, then let deterministic workflow logic decide what happens next.

• Use structured output to constrain the model to specific fields instead of relying on free-form text.

• Route high-impact outcomes through condition nodes, explicit checks, or human approval.

• Scope connected integration accounts with the minimum permissions required for the workflow.

• Test workflows against non-production systems before giving them access to live environments.

Patterns to avoid

Avoid these workflow designs:

• Giving an LLM broad access to many tools "just in case" it needs them.

• Letting an LLM read user-controlled text and directly send external messages in the same step.

• Letting an LLM update records, change permissions, or trigger destructive actions without review.

• Trusting free-form LLM output as if it were validated data.

• Using highly privileged integration accounts when a narrower account would work.

Safer workflow example

Instead of building a workflow like this:

1. Receive ticket text from a user.

2. Send the full text to an LLM with access to multiple write-capable tools.

3. Let the LLM decide which action to execute automatically.

Prefer a workflow like this:

1. Receive ticket text from a user.

2. Use an LLM node with structured output to classify the request or extract specific fields.

3. Use condition nodes to validate the result.

4. Call a limited action node, or require human approval, before changing data or contacting the user.

Practical rule of thumb

The safest pattern is to let the LLM analyze or propose, and let deterministic workflow logic decide whether an action should actually happen.

If a workflow can change data, contact people, or access sensitive systems, review the design with prompt injection in mind before publishing it.