Warning signs include replies that mention instructions never shown to the user, actions triggered by invisible HTML, unexpected attachment handling, or message behavior that changes after formatting is removed. Teams should also watch for unusual forwarding, deletion, or drafting patterns that do not match the visible email context. Those signals suggest the agent is trusting content it should ignore.
How to recognize an AI agent crossing email safety boundaries
Email is a useful place to test whether an AI agent is staying inside its intended guardrails because the medium contains both visible content and hidden mechanics. When the agent starts acting on content that the user never meaningfully saw, or when it changes behaviour based on formatting, embedded objects, or other non-obvious instructions, that is a strong sign the agent is treating email as a control surface rather than as plain correspondence.
That distinction matters because the boundary is not just about reading messages. It is about whether the agent is allowed to interpret, trust, and act on message content that could be deceptive, injected, or operationally unsafe. In practice, the warning signs are behavioural, not just technical: the agent begins to show it is following a hidden agenda embedded in the email instead of the user’s visible request.
One important signal is instruction drift. If the agent replies with details, tasks, or policy-like language that only appear in hidden HTML, quoted text, or other non-visible layers, it is no longer anchored to the visible email context. Another signal is content sensitivity, where stripping formatting, rendering the message in plain text, or changing the display order alters the agent’s action. That means the agent is reasoning over content it should not treat as authoritative.
A second cluster of signs is action shape. Unexpected attachment handling, unusual forwarding, deleting, archiving, or drafting patterns, and responses that do not match the user’s visible intent all suggest the agent has crossed from comprehension into unsafe execution. The concern is not only that the agent made a mistake, but that it may be allowing email content to steer privileged behaviour.
Agent behaviour that becomes more assertive, more specific, or more operational after encountering a particular message is also worth attention. If the same mailbox input produces a simple summary in one format but a task-bearing response in another, the agent may be responding to hidden prompts or adversarial content rather than to the user’s actual instructions. That is especially important when the agent has tool access or can take downstream actions on behalf of the user.
For practitioners, the operational question is whether the email layer is being treated as data or as directives. The moment message content can trigger forwarding, deletion, token use, or other side effects without explicit user confirmation, the email channel has become part of the agent’s authority boundary rather than a passive input source. See Browser and Computer-Use Agent Security Guide for a closely related pattern where user sessions and external content can steer agent action.
Why hidden email content is such a common failure mode
Hidden HTML, formatting tricks, and invisible instructions are effective because they exploit a basic trust mistake: the agent reads everything it can parse as if it were equally legitimate. Email clients and rendering engines often expose more structure than the user sees, so an attacker or malformed message can create a mismatch between visible intent and machine-readable instruction. The agent then becomes vulnerable to instruction smuggling, where the real payload is not the subject line or visible body but the embedded structure around it.
Attachment handling is another common failure mode because attachments often carry a different risk profile from the surrounding message. If the agent opens, summarizes, transcribes, or routes attachments in ways the user did not request, the workflow may be crossing a boundary between communication and execution. The same is true of forwarding and deletion, which are not merely interpretive actions but state-changing operations that can expose content, alter audit trails, or disrupt business workflows.
These failures are especially important when the agent operates with mailbox access, calendar access, or connected tooling. The more authority the agent has, the more a deceptively crafted email can translate into real-world impact. The warning signs therefore point to a broader control problem: whether the agent can separate user intent from message payload, and whether it can resist hidden instructions that arrive through a trusted channel.
For a wider security framing of this class of problem, OWASP Agentic AI Top 10 is useful because it groups identity and privilege abuse, tool misuse, and trust exploitation into the same operational picture. For threat-model depth, MITRE ATLAS adversarial AI threat matrix helps practitioners map how manipulation of inputs can influence downstream agent behaviour.
What to verify before trusting an email-capable agent
Start by checking whether the agent’s observed actions are explainable from the visible email content alone. If not, inspect whether hidden HTML, quoted text, inline images, or attachment content is steering the response. Next, compare behaviour across rendering modes, because a trustworthy agent should not change its safety decision simply because formatting was removed or simplified.
Also verify whether the agent is allowed to take the action it is taking. A summary agent that can forward, delete, draft, or extract attachments needs clear limits, because those are materially different operations with different blast radii. If a message can cause one of those actions without an explicit user approval step, the control design is too permissive for a mailbox-facing agent.
At scale, the most useful signal is repeatability. If a given class of email consistently produces odd drafting, unexpected forwarding, or an answer that seems to reference unseen instructions, that pattern is more important than any one message. The goal is not just to spot a bad output, but to identify the control weakness that allows message content to become agent authority.
Practitioner Guidance: Treat email as an adversarial input channel, not a trusted instruction source. The safest design is to require explicit user confirmation for side effects, keep rendering and action permissions tightly separated, and test the agent against hidden-content and formatting-variation cases before granting mailbox access.
What to prioritise: Focus first on side-effecting actions, because forwarding, deletion, drafting, and attachment handling reveal boundary failures faster than harmless summarisation does.
What to verify: Verify that the same message produces the same safety decision in plain text, HTML, and stripped-format views, and that the visible body alone explains any action taken.
Practitioner takeaway: The key test is not whether the agent can read email, but whether it can refuse to let unseen content become a command.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Email-triggered agent actions can exploit excess authority or hidden instructions. |
| ASI09 — Human-Agent Trust Exploitation | Hidden HTML and misleading message context manipulate agent trust decisions. | |
| Recommendation — Limit mailbox-driven actions to explicit, least-privilege approvals. Harden agents against deceptive email content and require user confirmation. | ||
| MITRE ATT&CK | T1566 — Phishing | Email is the primary delivery path for instruction-smuggling and deceptive content. |
| Recommendation — Detect malicious email delivery patterns and block suspicious message content. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agent mailbox actions should be bounded by minimal necessary authority. |
| AU-12 — Audit Generation | Behavioral anomalies in forwarding, deletion, and drafting require reliable traces. | |
| Recommendation — Restrict agent permissions to the minimum needed for each email task. Log agent email actions with enough detail to reconstruct decisions. | ||
Related resources from NHI Mgmt Group
- What are the signs that an LLM agent is operating outside its intended boundaries?
- What are the signs that agentic AI is operating outside its intended security boundaries?
- What are the signs that an AI agent workflow is failing governance or operating outside its intended scope?
- How can organisations tell whether an AI agent is operating outside its intended boundary?
