What is prompt injection, and why should a business owner care before connecting an agent to email?

The most common request I get from owners who have started using AI is some version of "can it just handle my inbox?" It’s a reasonable wish. The inbox is where the day disappears. It is also the one system in your business where total strangers can write whatever they like and have it land inside, which is exactly what makes this question matter.

What is prompt injection, in plain terms?

It is when content an AI reads changes how it behaves in ways nobody intended. OWASP separates two kinds. Direct injection comes from the person typing to the AI. Indirect injection arrives inside outside content, such as a website, file or email, that the AI reads as part of its job. For a business, the indirect kind is the one that matters.

A person reading a strange email knows the difference between the message and an order from their boss. A language model has a harder time with that line. OWASP notes that injected instructions don’t need to be visible or readable to a human at all, as long as the model parses them, so white text or a hidden block in a message can carry them.

Why is email the riskiest place to start?

Because an agent that reads email reads whatever anyone sends. OWASP’s entry on excessive agency describes this exact case: a mail-reading extension that could also send messages, tricked by instructions hidden in an incoming email into forwarding sensitive inbox contents to an attacker. The attacker never touched your systems. They just sent you an email.

The same pattern appears in OWASP’s prompt injection scenarios, which include a person asking an AI to summarise a web page with hidden instructions that led to their private conversation being sent out, and a vulnerability in an AI email assistant that allowed access to sensitive information and manipulation of email content.

What makes an email agent dangerous?

A specific combination. Simon Willison, the developer who named the pattern, calls it the lethal trifecta: access to your private data, exposure to untrusted content, and the ability to communicate externally. An email agent that can read your inbox and send messages has all three in one place. Take any one away and most of the risk goes with it.

Can’t the AI company just fix it?

Not fully, according to the security community. OWASP states it is unclear whether there are fool-proof methods of preventing prompt injection, and that research shows retrieval and fine-tuning techniques don’t fully mitigate it. Vendors reduce the rate. You still have to design as though some injected instruction will eventually get through, and limit what it could do.

Think of it the way you think about phishing. Your email provider filters most of it, and you still train staff and keep payments behind a second check, because the filter will miss one eventually. Prompt injection calls for the same posture, applied to software that reads mail on your behalf.

What should you set up before an agent reads your email?

1. Give it the fewest functions the job needs. If the job is sorting and summarising, it should not have send, forward or delete.
2. Use read-only access where the email system allows it, and a separate account or scope for anything more.
3. Keep a person pressing send. OWASP’s own example control is requiring the user to review and hit send on every email the extension drafts.
4. Keep outside content labelled as outside content in the agent’s instructions, and never let an email change the agent’s rules.
5. Don’t let the agent open links or attachments and then act on what it finds without a person in between.
6. Test it. Send it an email with a hidden instruction, such as a request to forward something, and confirm it does nothing.
7. Log what it does, so you can see an odd action the day it happens.

Does this only apply to email?

No. Email is the clearest case because strangers write to it every day, and the same logic covers any outside content an agent reads: web pages, shared documents, form submissions, reviews, support tickets. Before connecting any of them, ask the same three questions. Can it see private data? Is it reading content someone outside the company wrote? Can it send anything out? If all three answers are yes, change the design before you switch it on.

This is also why the order of connections matters. An agent that has worked safely on internal documents for a month becomes a different risk the day it also gets a web browser or an inbox, even though nothing about the agent itself changed.

What a safe first email agent looks like

It reads, sorts and drafts. Every draft sits in a folder until a named person reads it and sends it. It cannot forward, delete or change settings, and it has no access to the payment or client systems. That setup still takes most of the grind out of an inbox, and the worst thing a hidden instruction can do is produce a bad draft that someone throws away.