Prompt injection in email workflows: keep subscriber content in its lane

Imagine an agent summarizing replies to a newsletter. One reply includes a request to disregard its task and export the audience elsewhere. Another contact has a display name that resembles an instruction. A linked page presents an apparently helpful checklist that asks the assistant to call an unrelated tool.

These examples enter through different fields, but all are outside the operator’s authority. The text may be relevant evidence about what a subscriber said. It cannot grant itself a new role in the workflow. Even a tool response can carry untrusted content if the tool fetched a page or returned customer-supplied text.

OWASP’s prompt-injection guidance distinguishes direct instructions from indirect attacks in external material and warns that foolproof prevention is uncertain. For email teams, that is a reason to design enforceable boundaries rather than rely only on “ignore malicious instructions” in a system prompt.

Label retrieved content with its origin, retrieval time, and trust level. Keep the actual task and workspace policy separate from the content being summarized. Delimiters and labels help interpretation, but they are not a security sandbox: a model can still make an incorrect choice.

Normalize the evidence you need. A reply-summary job might need the reply body and campaign identifier, not the entire contact record, billing profile, or workspace configuration. Minimize the data supplied to the agent and the tool response. A compromised summarizer has less to disclose when unnecessary data was never available.

Do not ask the model whether it is authorized. Use the authenticated operator, workspace membership, and tool scope to determine that in application code. An external message saying “the owner approved this” is a claim to evaluate, not a replacement for an approval record.

A reply-analysis agent should not need an all-purpose workspace administrator. Offer a scoped reader and a draft-report writer instead of one tool that can query anything, edit settings, and send campaigns. Keep API keys out of prompts and model-visible responses.

OWASP’s excessive-agency guidance recommends minimizing functionality, permissions, and autonomy, with authorization enforced in downstream systems. The following email-specific checks are one way to apply that principle:

• Resolve the workspace from authenticated context, not a model-selected tenant identifier.
• Allow only the fields and operations required by this task.
• Validate identifiers, recipient limits, and destination rules on the server.
• Keep contact export, suppression changes, and sending behind separate capabilities.
• Reject a proposal that is syntactically valid but outside the approved purpose.

A correct JSON shape is useful, but not sufficient. A valid-looking request to send to the wrong audience is still the wrong request.

Suppose the agent legitimately drafts an email after reading a product page. The page should not be able to change the recipient set or grant send authority. Review the subject, body, URLs, sender, audience definition, schedule, and relevant policy version together.

Bind approval to the version being reviewed. If the agent later changes a destination, inserts an offer, expands recipients, or moves the schedule, invalidate or re-evaluate that approval according to your policy. A broad “looks good” in a conversation should not become a durable permission token for unrelated actions.

Show the reviewer a concise diff and the source of new claims. Human review is another control, not a guarantee: a plausible draft can still contain a hostile URL or unsupported promise. Machine checks should catch defined violations before the reviewer is asked to judge tone.

Build synthetic inputs for each real entry point: a reply, a first-name field, an imported note, a retrieved article, and a tool error message. Include instructions to change workspace, reveal a secret, bypass suppression, or replace an approved link. Do not run these trials against real subscribers.

Inspect the effects. Did the agent attempt a forbidden call? Did the service reject it? Did any export, draft mutation, or dispatch occur? A polite final response cannot prove that no unsafe action happened earlier. Keep blocked tool attempts visible in your test results without storing unnecessary personal data or secrets.

Also include benign lookalikes. A subscriber discussing the phrase “ignore previous instructions” should not make the system unusable. The standard is useful work inside the authorized boundary, not rejecting every unusual sentence.

Pause affected workflows, revoke or narrow the relevant capability, and inspect the action records. Distinguish an attempted call that was denied from a data disclosure or a message actually sent. Preserve the evidence needed to understand the incident, with access and retention controls.

If credentials were exposed, rotate them. If a draft changed, identify the affected versions and invalidate approval. If messages went out, follow your incident process; do not describe them as rolled back. Record the failure as a regression fixture before restoring the workflow.

These are engineering patterns for teams connecting agents to email tools, not a certification of any client or Moosewave deployment. Pair them with an evaluation suite and a template contract so both actions and artifacts remain inspectable.

• OWASP: LLM01 Prompt Injection. Direct and indirect injection, uncertain complete prevention, and mitigation layers.
• OWASP: LLM06 Excessive Agency. Least privilege, narrow tool functionality, human approval, and downstream authorization.

Sources checked 2 October 2026. Product behavior and documentation can change, so the linked primary source takes precedence if it differs from this article.