Email as input to a bounded AI workflow

An operator's email request becomes a bounded workflow task through a chain of separate decisions: verify who sent it, treat the message's own words as untrusted content, route the request into a known workflow, keep its execution scope small, have a person accept the result, and authorise delivery separately. Permissions come from what that workflow is configured to do — never from the wording of the email.

The requester, and the text they sent

Verification is about the sender: a known operator, confirmed through the operation's own accounts. The text is a different matter. Email content and attachments are a recognised indirect prompt-injection channel for AI assistants (OWASP), and prompt injection is any input that alters model behaviour in unintended ways (OWASP). So a quoted thread, forwarded message or attachment is evidence to inspect, not instructions to follow — and labelling text as trusted inside the prompt is not enforcement; permissions belong at the tool boundary.

Route into a known workflow

The request is classified into a predefined workflow — a climate-summary workflow, an alarm-review workflow — with explicit inputs, permitted actions and result requirements. Anthropic distinguishes these workflows, predefined code paths that give predictable behaviour for well-defined tasks, from free-running agents, and describes routing as a classification step directing input to a specialised follow-up (Anthropic). Routing is a decision, not an authorisation: selecting the climate-summary workflow does not grant the requester's authority, and the operation still decides which requests a given sender may trigger at all.

Keep execution scope bounded

Take an illustrative example, not a real case: an operator emails a request for one room's climate summary for the past week. The workflow needs read access to that room's records and a place to prepare the result. It does not thereby need write access to the climate control system, or authority to send mail on the operation's behalf. Privileges stay at the minimum necessary for the assigned task (NIST), because excessive functionality, permissions or autonomy turns an unintended model output into a consequential action (OWASP). How such boundaries are expressed is covered in our article on agent tool permissions.

Accept the result, then authorise delivery

A person — typically the technical operating owner — accepts the result: does it answer the request, trace to the permitted records, and contain only what the requester may see? Preparation and delivery are separate decisions; a drafted report is not a sent report. Where the request really needs a change — a setpoint, a schedule, a batch status — the workflow prepares a proposal for a named approver. A change is never performed because an email asked for it.

What to specify

Make the intake chain explicit before connecting email to agent work, the same way a task brief makes agent work checkable:

Which senders may trigger which workflows.
What each workflow may read, and for which rooms, batches and periods.
What may never be changed from this route.
Who accepts a result, and on what basis.
How delivery is authorised, and to whom.
How quoted or forwarded text is treated — as evidence, never as authority.

With those six answers written down, an email request becomes a checked task with defined permissions, and untrusted wording stays outside the authority boundary.

Manna configures the MIND Agentic Server around a customer's growing system, so an email request becomes a scoped workflow with defined permissions and delivery authority, and the technical operating owner stays in control. Discuss your growing system with us.

Prepared with AI assistance for Manna Insect Oy.