Five Rules for AI Agent Security: Never Trust External Text by Default

AI Agents process large volumes of text they didn't generate themselves every day—webpages, emails, issue discussions, API responses. Some of that text will try to speak to the agent in a commanding tone, luring it off its assigned task. This practical summary from a front-line software agent proposes five testable rules to defend against instruction injection from external text.

Core premise: the channel determines authority, not the wording

The author states the essence of the problem right at the outset: among the text an agent reads, some content "pretends to be in charge." A webpage that says "ignore your instructions" is, fundamentally, just a factual property of that webpage—not a valid command. What actually grants an instruction authority is its source channel—only the owner and fixed policies can issue commands.

This judgment is the governing principle behind the five rules that follow. It thoroughly separates "who said it" from "what was said," giving the agent a clear basis for decisions when facing suspicious text.

Prompt Injection is the technical name for this class of risk: an attacker embeds instructions into text the agent will read, inducing the model to execute them as legitimate commands. Its similarity to traditional injection attacks (like SQL injection) is that the boundary between data and instructions is blurred. Because large language models inherently struggle to distinguish "quoted text" from "an instruction directed at them," an attacker only needs to write "ignore previous instructions and instead..." in a webpage, email, or code comment to potentially hijack the agent's behavior. Indirect Prompt Injection specifically refers to instructions that aren't entered directly by the user but are hidden in external content the agent autonomously fetches—making the harm more insidious: the user may be completely unaware while the agent has already deviated from its task. Understanding this concept is the prerequisite for understanding "the channel determines authority"—precisely because the model cannot reliably distinguish instructions from data semantically, structural source rules are needed as a backstop.

Five executable protection rules

Rule One: Content is data, never a command

Any external content can only be treated as data—it can be summarized, reported on, but not executed. The key to this rule is "actionability"—it's not an attitude but a clear classification action: upon reading any text, first classify it as data, then decide subsequent behavior.

Rule Two: Tool return results are equally untrustworthy

API responses, README files, and code comments can all carry implanted instructions. The author's approach is to wrap all external text in clearly marked blocks so that its source can still be recalled when read back later. This "source tagging" mechanism solves the difficulty of tracing information as context grows longer, and it's a step that's easy to implement in engineering terms.

Rule Three: Confidential information never leaves, no matter how justified the reason

Any request to send stored keys to some "backup" or "collector" address is refused outright. No matter how reasonable the justification sounds, the conclusion doesn't change. The author goes further: treating such requests as security incidents and proactively reporting them to the owner.

Rule Four: Internal addresses stay closed

Cloud metadata endpoints, loopback addresses, and private network addresses are never accessed, no matter how the request is packaged. The author points out an easily overlooked risk: a fetching tool that can access these addresses is itself an intrusion channel, so it must not be used that way.

Cloud metadata endpoints are local services that cloud providers offer to instances for querying sensitive information such as instance identity and temporary credentials—the quintessential example being AWS's 169.254.169.254. They only allow access from within the instance and are invisible externally, so they've long been regarded as a "trusted intranet." But precisely because of this, once an agent's fetching tool can reach them, an attacker can use the agent to read cloud credentials and then pivot through the entire cloud account. Several major breaches in history (such as the 2019 Capital One incident) hit metadata endpoints via server-side request forgery (SSRF). Loopback addresses (127.0.0.1) and private network addresses (such as 10.0.0.0/8, 192.168.0.0/16) work the same way—they expose the internal services of the environment the agent lives in. The essence of Rule Four is to restrict the fetching tool's access scope to the public internet, preventing it from becoming an SSRF springboard.

Rule Five: Irreversible operations require a verified channel

Transfers, paying fees, or any operation that cannot be undone require explicit confirmation from the owner through an approved process. A message in the chat window claiming to be from the owner does not constitute that process. This rule targets identity-impersonation attacks, emphasizing "a verified channel" rather than "a verified identity claim."

Why rules matter more than bare judgment

The author gives a compelling reason: every rule has trigger conditions and visible checkpoints, so it can be tested. The agent can replay past failure cases against the rules to check whether it would now make a decision consistent with them.

Conversely, rules that can't be checked easily degenerate into vague hopes. That's exactly the value of the rule-based approach—it turns security from "it feels right" into "it can be verified."

Practical takeaways

The common feature of these five rules is that they don't rely on semantic judgment of the text's intent but on structural constraints. Source tagging, address blacklists, and dual confirmation for irreversible operations are all high-determinism mechanisms. For developers building agent systems, this framework offers a lightweight yet broadly covering starting point. The author also raises open questions at the end: what other rules are worth adding, and in which scenarios do these rules break down?