Practical controls for AI-assisted inbox workflows

Keep incoming email from becoming authority over your AI workflow

An incoming email may contain a customer request, an invoice or a supplier update. It may also contain instructions aimed at the AI reading it. Prompt injection is the attempt to make that external content redirect the system away from its authorised task. The control design must account for what the reader can access and what it can cause to happen.

This guide focuses on defensive workflow design for businesses using AI to triage, extract or draft from email. No single instruction or filter should be presented as complete protection. The examples are hypothetical, and the first assessment should use safe test messages with no live sending or record-changing permissions.

Review your AI email boundaries (03) 9003 0111

Email security workflow showing external content, restricted interpretation, checked proposal and authorised review. Select the diagram to view it full size.

Four boundaries to establish before reading messages

Purpose

What task did the business authorise?

An email can supply information without changing the workflow's purpose or rules.

Access

What information can the reader retrieve?

Limit exposure to the records needed for the permitted task and recipient.

Action

What can happen after interpretation?

Separate a suggested reply or field from permission to send, disclose or update.

Evidence

How do you know the boundary held?

Inspect attempted actions and resulting state, not only a reassuring final response.

Email content and business authority are different things

A defensive design assumes that external text can be misleading. It makes consequential actions depend on controls outside that text.

Treat attachments as external content too

The risk does not stop at the visible email body. Attachments, quoted threads and linked pages can also contain material the system reads. Inventory the surfaces included in the workflow and apply the same trust boundary to them. Do not grant an attached document authority merely because it is formatted as a policy or appears inside an otherwise familiar conversation.

Keep the authorised task explicit

Write the workflow purpose outside the incoming material. For example, extracting invoice fields into a review record is a narrower task than handling whatever the sender asks. The design should distinguish content describing the sender's request from instructions controlling the system. That separation must be supported by action permissions, not only by telling the model to be careful.

Limit what a mistaken interpretation can do

A reader that only produces a draft for an authorised reviewer has a different exposure from one that can search all files and send externally. Scope access and actions to the minimum needed for the task. Confirm those restrictions in the actual integration account and execution path rather than assuming a user-interface label makes the permissions narrow.

Inspect behaviour after the answer

A model may say it ignored suspicious text while a tool request or generated link still carries information elsewhere. Review the action trace and destination state as part of testing. The acceptance question is whether the workflow stayed within the authorised data and action boundaries, including cases where it declined, failed or received contradictory external instructions.

Six layers for a defensive email workflow

These are controls to scope and verify in the environment you use. They reduce exposure and improve oversight; they are not a promise that prompt injection has been eliminated.

A fixed task boundary

Define the message's role

Specify whether the email is being classified, summarised, used to populate a draft or considered as evidence for a business decision. Keep that purpose in trusted workflow configuration. Treat instructions inside the message as content to assess under that purpose. If a sender requests an action outside scope, route the request to the existing human process rather than expanding the automation's authority.

A smaller information surface

Minimise the context provided

Give the reader only the message content and supporting records necessary for the task. Avoid connecting a broad mailbox or document search when a narrow record lookup is sufficient. Check attachment handling and quoted-thread inclusion so unrelated information is not added by convenience. Data minimisation limits what can be exposed if the system interprets external content incorrectly.

An enforceable action boundary

Restrict tool permissions

Separate read, draft and write capabilities. Use integration permissions and application-side controls that prevent disallowed destinations or record changes even if a model requests them. Confirm which account executes the action and what that account can do. Where permissions cannot be narrowed adequately, keep the workflow in a review-only stage rather than relying on a natural-language prohibition.

A checked proposal

Validate proposed outputs

Treat extracted fields and suggested actions as untrusted proposals until the relevant checks pass. Check recipient identity, permitted destinations, required evidence and the authorised action type using explicit rules. A request in an email must not be sufficient authority to change supplier details, disclose another customer's information or send a file. Keep the original message available for review without allowing it to alter the validator.

A reviewable consequence

Use meaningful human review

Show the reviewer the proposed action, destination, relevant source and any changed fields before approval. A generic approve button without consequences encourages accidental authorisation. Keep review separate from the external message's wording and make suspicious requests visible in plain language. The reviewer should understand what will leave the business or change in a system, not merely approve a polished summary.

Evidence of controlled behaviour

Test and monitor boundary failures

Use controlled messages that contain conflicting instructions, unexpected requests and misleading references. Include ordinary legitimate messages so the workflow is not judged only on refusal. Inspect the actual permitted and attempted actions, failures and resulting records. Retain enough evidence to investigate an incident without logging unnecessary sensitive content. Reassess when access or capabilities expand.

Business email scenarios worth testing safely

Task	Traditional	Defensive workflow response	Notes
Invoice includes a request to change process rules	Treat every sentence as an instruction	Extract the relevant invoice content under existing rules	A supplier document cannot authorise the system to bypass your approval process.
Customer asks for another customer's attachment	Search broadly and prepare the file	Check identity, scope and disclosure authority	A plausible reason in the email is not evidence that the requester may receive the data.
Quoted thread looks like an internal instruction	Promote quoted text to trusted policy	Preserve it as external conversation content	Use approved workflow configuration for authority, not a message's claimed origin.
Message asks to send a report to a new address	Follow the sender's destination	Require the authorised recipient rule and review	Display the actual destination and data included before any permitted send.
Attachment claims to update security policy	Use the document as the new rulebook	Refer the request through the policy owner's process	Formatting, logos and urgency do not establish authority to modify controls.
A linked page requests extra information	Allow the browser to follow its instructions	Limit navigation and data movement to the agreed task	Confirm how links are handled before connecting browsing to sensitive context.
A legitimate customer request is unusual	Reject everything unfamiliar	Create a review task with the source and request	A defensive system should preserve useful business work while withholding unsupported actions.
The reader refuses but an action was attempted	Count the final refusal as safe	Inspect the action trace and resulting state	The evidence must cover the whole workflow rather than only the visible answer.

Mistakes that weaken the boundary

The prompt is the only control

A natural-language rule can describe the intended behaviour, but it should not be the only thing preventing a consequential action. Restrict permissions and validate proposed actions outside the external content. Test the actual account and path that would execute the action.

A filter is presented as complete prevention

Detection can miss unfamiliar or indirect attempts and may also flag legitimate content. Keep layered controls and a review path. Describe test coverage honestly and avoid claiming that a clean test run proves immunity to every future message.

Internal-looking content gets automatic trust

An email can contain a forwarded policy, copied signature or quoted instruction. Treat those as claims to verify through the approved source. Do not let a message declare its own trust level or grant access to records because it names a senior employee.

The approval screen hides the destination

A reviewer needs to see who will receive information and what will be sent. Show expanded recipient details and the relevant content before approval. Do not summarise away the sensitive consequence behind a label such as complete task.

Logs become a second exposure

Action evidence is useful, but indiscriminate logging can copy sensitive message contents into additional systems. Define what is retained, who can access it and how long it is needed. Prefer identifiers and targeted excerpts where they provide sufficient investigative context.

A safe pilot gains broad permissions later

Adding mailbox search, external sending or file access changes the exposure even if the prompt stays the same. Treat capability expansion as a new boundary review. Repeat tests against the new permissions and update the approved task definition before rollout.

Worked example: a supplier message asks for a wider disclosure

Imagine a hypothetical invoice-triage workflow whose authorised task is to identify the supplier, extract the invoice reference and prepare a review record. An incoming message also asks the assistant to find a previous customer report and send it to a newly supplied address. The request may be written politely and may claim urgency. It is still outside the defined invoice-triage task and does not establish disclosure authority.

In the proposed design, the reader receives only the invoice material and the narrow supplier lookup needed for classification. It has no broad customer-document search and no external-send capability. If it mentions the additional request in its output, the application routes that request to a reviewer rather than executing it. The review record preserves the relevant message context without adding the requested report or expanding the task.

The acceptance test should inspect more than the final text. Verify that no unrelated lookup was performed, no file was attached, no message was sent and no destination record was changed outside scope. Check the account permissions separately from the model response. If the system refused the request only because the test data lacked a report, the access boundary has not been demonstrated.

Now test a legitimate variation: the supplier asks which invoice reference is missing from the review record. The narrow workflow may be able to prepare a suitable draft or referral under the agreed process. A design that blocks all unusual language is not necessarily useful. The distinction is the authorised task and permitted evidence, not whether a message contains a request or uses an urgent tone.

A checklist for the owner of an AI-assisted mailbox

Write down the exact task in one sentence and list the records it needs. Then list every capability connected to the workflow, including search, browsing, drafting, sending and record updates. Identify the executing account for each. Compare the two lists: any capability that is unnecessary for the task needs a reason to remain connected or should be removed from the proposed scope.

Review the approval interface using a deliberately unexpected destination and a draft containing information outside the task. Check whether the reviewer can see the consequence clearly before approval. Inspect what happens when the reviewer declines and whether another automated path can still perform the action. Approval should be tied to the specific proposed action, not act as a broad permission for future requests.

Keep a record of the safe test messages, workflow configuration and observed boundaries. Include ordinary messages that completed properly and conflicting messages that remained restricted. Official guidance such as OpenAI’s Understanding prompt injections discusses the broader challenge and the value of limiting access; the workflow controls here are proposed design requirements, not a claim that any particular product already enforces them for your business.

Reviewing a suspected incident without creating another exposure

When a suspicious message is identified, first establish what the workflow actually read and what capabilities were available at that time. Preserve the message identifier and configuration version under controlled access. Do not forward the full message and every connected record to a wide distribution list for convenience. The investigation needs enough evidence to reconstruct the event while keeping unrelated customer and business information within its existing boundaries.

Separate attempted redirection from an observed action. A message containing conflicting instructions shows an attempt or suspicious content, not necessarily a successful compromise. Conversely, a reassuring refusal in the final response does not establish that no tool action occurred. Inspect the relevant action requests and destination state. Record what is known, what is not yet verified and which evidence would settle the uncertainty.

Use the existing operational response owner to decide whether the affected workflow should remain restricted, pause or continue under additional review. Do not grant broader access to the same reader merely to investigate the suspicious request. A separate authorised review path should examine the evidence. Where external services are involved, confirm the available logs and access before promising that every intermediate event can be reconstructed.

After addressing the demonstrated issue, turn a safely sanitised version of the case into a regression test. Preserve the behaviour being tested without retaining unnecessary sensitive content. Re-run both that case and legitimate messages that the control might now reject. Document the boundary that changed, such as a removed capability or a stricter recipient check. Avoid reporting the incident as proof that all future prompt injection is prevented; state the actual repair and tested coverage.

How Yes AI can help assess the workflow

Map data and action boundaries

We can scope the messages, attachments, records and tools involved in one workflow. The deliverable should identify where external content is read and where a proposed interpretation can cause an action. This provides a concrete basis for permission and review decisions.

Design a restricted pilot

A proposed pilot can use approved test messages and draft-only outputs with no live sending or record modification. We can define the cases to exercise and the evidence needed to assess them. Environment access and vendor-specific controls must be confirmed before implementation.

Make approvals useful

We can help design the review screen around the actual consequence: destination, disclosed content, changed fields and supporting evidence. The aim is to make an informed decision possible without requiring staff to inspect technical traces for every ordinary message.

Say when the access is too broad

If the available integration cannot enforce a suitable boundary, a narrower task or manual review may be the appropriate choice. We will not treat an instruction in a prompt as a substitute for a missing permission control. The next step may be reducing scope rather than adding another model.

Assess one inbox workflow without granting new authority

Start with a controlled environment and a clear purpose. This guide concerns defensive assessment, not permission to test other organisations or live customer accounts.

Inventory the surfaces

List message bodies, attachments, quoted history, links and supporting lookups. Record the information each surface exposes and the account that accesses it.

Define permitted behaviour

State the task, allowed records, destinations and actions. Identify the point where human approval or an existing business process is required.

Check enforceable controls

Inspect integration permissions and application validation. Confirm that a disallowed action is blocked even when it appears as a model proposal.

Exercise safe scenarios

Run approved normal and conflicting test messages in a non-production environment. Inspect attempted actions and destination state, including failures and partial completion.

Maintain the boundary

Record the approved scope and evidence. Reassess when tools, permissions or data access change, and keep a response procedure for suspected boundary failures.

Turn this guide into your next steps

Use these steps to prepare your own review. Tick a step once you have recorded its evidence. Ticks are temporary and are not saved or sent to us.

Bring one example of the process you want to improve. We can help define the scope, checks and next decision. Consultation options and any fee are shown before you book.

Review your AI email boundaries

FAQ

What is prompt injection in an email workflow?

It is an attempt to use external message content to redirect an AI system away from its authorised instructions or task. The content might be in the email, an attachment or another source the workflow reads. The defensive goal is to keep that material from becoming authority over access, disclosure or actions.

Can a sender change our automation just by writing instructions?

Whether an attempt affects behaviour depends on the design and controls. Do not assume it is impossible, and do not treat every suspicious message as proof of compromise. Define the permitted task, restrict capabilities and inspect actual action evidence. A safe test can establish whether specific boundaries held under the scenarios tested.

Is telling the AI to ignore malicious instructions enough?

It is useful to state the intended behaviour, but consequential actions should also be constrained by permissions and explicit validation. Keep human review where appropriate. A defensive design should remain limited even when the reader proposes something outside scope, rather than depending entirely on the reader interpreting every message correctly.

Does draft-only mode solve the whole problem?

It reduces the immediate consequence of automatic sending, but drafts can still contain inappropriate disclosures or misleading content. A reviewer must see the proposed recipient and message before sending. Also verify whether the workflow has other write or search permissions that remain active despite its draft-only label.

Should we block every message containing instructions?

No. Ordinary business messages contain legitimate requests. The distinction is whether the request falls within the authorised task and has the required evidence and approval. Preserve unusual requests for review instead of silently deleting useful work. Test both legitimate messages and conflicting content so the workflow is useful as well as restricted.

What should we retain when something suspicious happens?

Keep the relevant message identifier, workflow version, permitted scope, action proposals and observed outcome under controlled access. Retain source content only as needed for investigation under your organisation's policy. Avoid copying credentials or unrelated personal information into incident notes. The evidence should establish what was read and what actually happened.

Can Yes AI guarantee that prompt injection is prevented?

No. A scoped review can identify exposure, propose layered controls and test defined scenarios. It should report the exact coverage and unresolved limitations. Changes in tools, access and external content can introduce new risks. The sensible objective is a restricted, observable workflow with a practical response path, not a claim of universal immunity.

Check what an incoming message can actually cause

Yes AI can scope a defensive review of one email workflow, including its data access, action permissions and approval path. Start with the task and the consequences you need to control.