An AI assistant that summarizes your inbox can save you from reading every long thread. Connecting it also gives it access to material written by people outside your organization. Some of that material may try to influence the assistant itself.
This is one reason an inbox connection deserves more thought than turning on a convenient feature. Before connecting anything, decide what the assistant is allowed to read, what it is allowed to do and what must wait for a person.
What prompt injection means
Prompt injection happens when an AI system treats instructions found in material it is reading as instructions it should follow. That material might be an email, a document, a webpage or a result returned by another tool. With an indirect prompt injection, the person supplying the content does not need to be the person using the assistant.
The difficulty is that a language model does not provide a reliable security boundary between your request and the outside material included with it. The UK National Cyber Security Centre warns that these risks need to be managed through system design and operation, rather than assuming a filter can eliminate them. Read the NCSC explanation.
The practical question is what could happen if the assistant follows the wrong instruction.
A harmless example
Imagine asking an assistant for three plain bullet points summarizing a test newsletter. The newsletter includes a playful request that any summary be written as a poem. If the assistant returns a poem, the material it was supposed to summarize has influenced how it followed your request.
Nothing serious happened in that example. It still shows why a sentence in an email should not be treated as authority to change how a work system behaves. The sender may be providing information for your staff; that does not give the sender permission to direct your assistant.
An assistant with broader capabilities could do more than produce an odd summary. The possible consequences depend on the information it can access and the actions its connected tools permit.
Start with the smallest useful connection
Write down one job before connecting an account. “Summarize the public enquiries sent to this shared mailbox” is a clearer starting point than “help with my work.”
Then match the permissions to that job:
- Give access only to the mailbox, folder or records needed, where the product supports that restriction.
- Prefer read-only access when the job is reading. An assistant preparing a summary does not need permission to send, delete or change messages.
- Leave unrelated file stores, calendars, customer records and payment systems disconnected.
- Remove unused integrations and review access when a staff member leaves or a pilot ends.
This is least privilege: limiting a tool to the access it actually needs. OWASP identifies excessive functionality, permissions and autonomy as separate sources of risk, and recommends constraining each one. See OWASP’s guidance on excessive agency.
Read-only is useful, but it does not make unrestricted reading harmless. An assistant may still expose sensitive details in an answer or send data through another enabled capability. Ask where retrieved information can go, as well as whether the mailbox connector can write.
Keep sending and other consequential actions behind approval
For a small organization starting out, I would make inbox assistance draft-only and leave auto-send off. Staff should see the complete proposed message, recipients and attachments, and approve that specific send after reviewing them.
Apply the same approach to publishing, deleting records, changing permissions, spending money or updating important business information. A person needs enough context to make a real decision. A vague “continue?” button is a weak review point.
The approval requirement should be enforced by the software that performs the action. Do not rely only on a sentence in the assistant’s instructions telling it to ask first. OWASP recommends human approval for high-impact actions and authorization checks in the systems carrying them out. Read the recommended controls.
If the product cannot separate reading from sending, or cannot show exactly what you are approving, that is a reason to choose a narrower workflow or wait.
Keep a record and a way to stop
Before a pilot, decide who can disconnect the assistant and how to do it. That person should not need to search for the original installer during an incident.
Ask for records of which connected tool acted, what action was proposed, which account approved it and whether it succeeded. Logs can help you investigate unexpected behaviour, but they can also contain private information. Limit who can see them and agree on an appropriate retention period. The NCSC’s secure AI development guidance includes monitoring and maintaining systems after deployment.
Define a small set of reasons to stop the pilot: an unapproved send, access beyond the intended scope, unexpected disclosure or outputs that staff cannot reliably check. When something occurs, pause the connection, preserve appropriate records and ask the person responsible for security or privacy to assess it. Avoid forwarding sensitive logs widely while trying to explain the problem.
Questions to ask a vendor before connecting
You do not need to know how the model was built to ask useful questions:
- What exactly can this connection read and change? Ask to see the permission scopes and any limits on folders, mailboxes or users.
- Can it be read-only or draft-only? Find out whether sending and deletion can be disabled by an administrator.
- Where is approval enforced? Ask whether a consequential action is technically blocked until the user approves its final details.
- What other tools can receive the information it reads? Include web access, extensions, connected apps and background tasks.
- What evidence can we review? Ask for activity records, permission-change history and the process for reporting an incident.
- How do we shut it off? Confirm how to revoke access and what happens to retained copies of emails or files.
- What risks remain? Be cautious of promises that prompt injection has been completely solved. Ask how the provider limits the consequences when a model behaves unexpectedly.
A sensible first pilot
Use fictional messages and non-sensitive test documents first. Choose one bounded task, such as preparing summaries for a person to review. Keep sending disabled and check whether the result stays within the task, whether sources are visible and whether access matches what you approved.
Before moving to real information, review privacy requirements, provider terms and staff responsibilities. Keep the pilot small enough that someone can check every result. Record what worked, what needed correction and whether the time saved justified the review effort.
A connected assistant is most useful when its job and limits are clear. Decide those limits before granting access, then revisit them when the product, permissions or workflow changes.