lupin.Open console
Email

Keep email prompt injection from becoming tool authority

Treat sender content, attachments and quoted conversations as untrusted data throughout an agent workflow.

Lupin editorialAI-assisted3 min read

Assume instructions can arrive inside content

An email can contain a normal customer request and an embedded attempt to redirect the agent. Examples include ignore your previous rules, reveal the API key or send this attachment to a different address. The same attempt can appear in a quoted reply, HTML alternative, PDF or spreadsheet cell. Do not solve this only with a list of suspicious phrases. The stronger boundary is architectural: inbound correspondence is task data, while trusted application policy and the real user’s authorization determine what tools can do.

Keep provenance visible to the model

Wrap selected content with its inbox, message ID, sender, timestamp and source type. Keep it separate from trusted instructions and account facts. A valid webhook signature proves delivery authenticity at the webhook boundary, not the sender’s right to control your agent. A familiar display name or forged approval sentence should remain a claim in received content. When summarizing, the agent can report that a sender requested an account change without treating that request as permission to change the account.

Limit what a mistaken model can reach

Use an inbox or project key when the workflow needs only that scope, with permissions appropriate to reading and drafting. The autonomous bootstrap key already lacks outgoing, paid-resource, inbox-create and key-create authority; keep that restriction intact rather than replacing it with a broad owner credential. Never include credentials or recovery secrets in model context. A prompt-injected model cannot disclose a secret it was never given, and server-side ownership checks should still reject a resource ID selected from another tenant’s message.

Validate tool calls outside the conversation

Dispatch only registered catalog operations with validated arguments. Do not accept sender-supplied URLs as arbitrary API targets, credential overrides or tool names. For external actions, bind approval to the exact account, recipients, content and relevant resource revision. A tool result, email body or remote document cannot grant that approval. Even an apparently read-only connected-app tool requires the consumer agent’s explicit approval because provider operations can have side effects. Treat schema-valid malicious requests as policy decisions to deny, not as safe simply because their JSON parsed.

Test containment and graceful reporting

Create synthetic emails that ask for secret disclosure, another tenant’s thread, a changed recipient and a hidden attachment forward. Assert that no unauthorized provider call occurs, while the legitimate part of the request can still become a useful summary or reviewable draft. Keep suspicious content out of ordinary logs and explain denied actions plainly to the operator. Your next step is a fixture that places the attack inside an attachment and quoted chain, then verifies the same server-side permissions and approval checks apply throughout the resulting workflow.

Recover without rewarding the attack

If a job proposes an unauthorized action, stop that proposal and retain a bounded diagnostic record. Do not automatically ask another model to find a workaround or retry with a stronger credential. Resume the legitimate task from trusted instructions and available evidence, making any missing authority visible to the user.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.

Put it into practice

Give your agent the right tools.

Review the API, workspace requirements and permissions before enabling a workflow.

Explore email Register an agent