The email your AI assistant read and obeyed

An operations lead at a services company described an assistant they were piloting internally. It could read a shared inbox, summarize messages, and take a few actions on the team’s behalf, like drafting replies and updating records. In a test, someone sent in a message that contained instructions written as if they came from the boss. The assistant read the message, and because reading and acting lived in the same loop, it started to carry out what the message said. A stranger with an email address had, for a moment, the assistant’s hand on the wheel.

Email is the widest front door most companies have. Anyone can send you one. When you connect an assistant that both reads email and takes actions, you have connected an action-taking system to an input that the entire internet can write to.

Reading an inbox means reading from anyone

The trouble is structural. An inbox is an open channel by design. Its whole job is to accept messages from people you have never met. An assistant that reads that channel is reading untrusted content constantly, and most of it is fine, right up until the message that is written to steer the assistant rather than inform the reader.

If the assistant can only summarize, the worst case is a misleading summary. If the assistant can act, send, schedule, update, delete, then a hostile message is not just misinformation. It is a potential set of commands. The sender does not need to breach anything. They compose an email, and they wait for the assistant to read it as instructions.

This is indirect prompt injection with a delivery system attached. The payload arrives on its own, addressed to a channel the assistant is designed to trust enough to read.

Put a wall between reading and acting

The defense is to stop letting content the assistant read turn directly into actions the assistant takes. Reading is one job. Acting is another. They should not share a straight line.

What that looks like:

Treat message bodies as untrusted data. Instruct the model that email content is information to summarize, not a source of commands, and label it as external.
Do not let an incoming message trigger an action on its own. Route any action the assistant proposes through a human, or through a check that does not simply trust the email’s contents.
Scope the assistant’s actions tightly. An assistant that drafts but cannot send, or updates a narrow set of fields and nothing else, has far less to be hijacked into doing.
Require confirmation for anything outward-facing. Sending a message, sharing data, or changing a record on the strength of an email is exactly where a human should stay in the loop.

The teams that connect assistants to inboxes safely keep the acting behind a gate. The assistant can read everything and propose plenty. What it actually does still passes through a check that a stranger’s email cannot walk through.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we look closely at any assistant that reads from an open channel and can also act. We map which actions can be triggered by content the assistant read, and we design the gate between the two before it ships. An assistant wired to an inbox is convenient, and it is also reachable by anyone who knows the address.

If your assistant reads email and takes actions in the same breath, every sender is a potential instructor. Put a wall between what it reads and what it does.