Why do untrusted emails, documents, and web content create risk for agent assistants?

Why untrusted content becomes an execution path for agents

Untrusted email, documents, and web pages are risky for agent assistants because they can influence the agent’s next action, not just what the human sees. Once an assistant can read inbound content and trigger tool calls, message content can function like instructions, prompts, or workflow inputs. That changes the threat model from “malicious text” to “potential command source.”

The core issue is trust boundary collapse. A normal user treats content as data, but an agent may parse it, summarise it, follow links, extract tasks, or convert it into actions in email, chat, browsers, tickets, code, or SaaS tools. In practice, that means malicious content can attempt indirect prompt injection, task steering, or tool misuse, especially when the agent is allowed to act on behalf of a user.

Agentic systems become more exposed when the content source is external, the instruction hierarchy is weak, or the agent has broad permissions. Guidance on agentic AI security and browser and computer-use agent security both stress the same practical point: content ingestion and action execution must be separated by policy, scope, and confirmation.

How poisoned content steers agent behaviour

Attackers do not need the content to look obviously malicious. They only need the agent to treat it as credible enough to influence its planning. A poisoned email can ask the assistant to forward data, open a link, approve a request, or change a setting. A hostile document can embed instructions that override the user’s real intent. A web page can hide instructions in visible text, metadata, or dynamically loaded content.

That is why agent content handling is closer to application security than classic spam filtering. The relevant question is not only “did we block bad mail?” but “did any untrusted text gain the ability to alter an agent’s state or trigger an external side effect?” If the answer is yes, the content channel has become an execution surface.

AI agent authorisation guidance and zero trust for AI agents are relevant because they frame the key control decision as per-action authority, not ambient trust. The agent may read the content, but it should not inherit the right to act simply because the content asked it to.

What good controls have to do differently

The defensive model needs explicit separation between interpretation and execution. Reading content is low risk by itself; converting that content into a tool invocation, credentialed request, or workflow update is the point where policy must intervene. That means agents should operate with constrained scopes, step-up confirmation for sensitive actions, and hard checks on whether an instruction came from the user, the system, or an untrusted source.

It also means the security team should treat source reputation, content origin, and action context as separate signals. An external message can be legitimate enough to display but still unsafe to operationalise. Likewise, a document can be safe to summarise but unsafe to let drive a browser session, calendar change, file transfer, or code execution.

The strongest practical pattern is to make the agent prove why an action is allowed before it performs it. That is the same control logic behind MCP security and the broader threat modelling for AI agents approach, where tool use, trust boundaries, and identity context are treated as first-class design inputs.

Risk and Threat Considerations

When untrusted content can influence an assistant that has tool access, the main risk is covert command injection through a channel the user expects to be passive. The attacker is not trying to “hack the email” in the traditional sense, they are trying to get the agent to do work for them by hijacking its interpretation of the message.

Failure mechanism: The agent reads external text, assigns it more authority than it deserves, and turns that text into an action, such as exfiltrating data, approving a request, following a hostile link, or modifying records through connected tools.

Impact: The result can be unauthorized access, data disclosure, fraudulent workflow execution, or lateral movement through integrated systems, especially when the agent has standing privileges or can reuse a signed-in session.

Practitioner Guidance

What to verify: Verify whether each agent action can be traced to a trusted user intent, a trusted system rule, or an approved policy path. If the only “reason” for the action is content the agent read, treat that as an unsafe default.

Decision rule: If content can change state, spend money, expose data, or invoke a privileged tool, require an explicit policy check or human confirmation before execution. If the content only needs to be summarised or displayed, keep it read-only and prevent downstream action chaining.

What good looks like: The agent can ingest untrusted content without inheriting authority from it. The observable safe state is one where external text may inform the assistant, but it cannot silently become a command source, a delegation source, or a permission source.

Practitioner takeaway: The security boundary is not the inbox, document, or webpage, it is the moment content becomes action. Design the system so untrusted input can influence analysis, but not authority.

Related resources from NHI Mgmt Group

• When does AI agent access create more risk than it reduces?
• When do AI agent credentials create more risk than they reduce?
• Why do valid credentials still create security risk when an AI agent processes untrusted content?
• Why do AI agents create new risk in non-human identity management?