> For the complete documentation index, see [llms.txt](https://docs.ebbot.ai/ebbot-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ebbot.ai/ebbot-docs/core-capabilities/automations/workflow-security-and-prompt-injection.md).

# Workflow Security and Prompt Injection

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](https://simonwillison.net/2025/Jun/16/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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ebbot.ai/ebbot-docs/core-capabilities/automations/workflow-security-and-prompt-injection.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.