Where Prompts Stop: Sandboxes, Networks, and Tenant Boundaries

Agentao’s permission gate decides whether a proposed call should proceed, but it cannot by itself define everything that call can reach. This chapter diagnoses the failures that appear when untrusted content manipulates the model, a permitted shell command reaches too much of the machine, a URL crosses an internal network boundary, or two tenants share process-level state. The practical judgment is that prompts and runtime rules are necessary layers, while filesystem, network, credential, and identity boundaries must be enforced independently.

The first symptom: data starts giving orders

Prompt injection is often described as a hostile user message, but the more difficult cases arrive through data the user asked the agent to inspect. A web page can contain hidden instructions. A file can end with a sentence telling the model to ignore its task. A customer ticket or database result can ask the agent to reveal its tools. An MCP server can return text that looks like a system message. Once that content is placed in the model’s context, the model has to distinguish information from instructions, and that distinction is not perfectly reliable.

Agentao’s guidance offers model-facing defenses: hard constraints in project instructions, conventions for tagging external content as data, and a smaller tool surface. These are useful because they shape how the model interprets a result. A tool can wrap fetched text in a data marker and tell the model not to follow instructions found inside it. A project instruction can say that credentials must never appear in replies and that “ignore previous rules” in tool output is suspicious. Removing an unnecessary shell or web tool eliminates entire classes of proposed actions.

But none of these measures is a hard authorization boundary. If a malicious page persuades the model to call a tool, the PermissionEngine still needs to decide whether that call can run. If a tool is allowed, its implementation and the surrounding operating system still determine what it can reach. The right diagnosis is therefore not “the prompt defense failed, so everything is lost.” It is “the prompt layer is one control, and the next independent layer should still hold.”

Shell risk has three different causes

Shell execution combines model interpretation, command policy, and operating-system authority. Agentao documents three progressive layers. PermissionEngine can classify the command before execution. confirm_tool() can ask a person or host policy about an ambiguous command. An optional OS-level sandbox can limit file and network effects after the command has been approved. Each layer addresses a different point in the failure path.

The PermissionEngine is the cheapest place to reject a command that should never run. A host can permit a narrow read-only set, deny known-dangerous patterns, and ask about the remainder. This reduces unnecessary prompts and avoids launching a process that policy already knows is unacceptable. It also produces a more intelligible refusal for the model. The limitation is semantic: command-string matching is not the same as proving every effect of a shell program. Shell syntax, environment variables, child processes, and downloaded code can make a superficially simple command more powerful than its text suggests.

Confirmation adds a human or host-owned decision at the point of uncertainty.