Two Kinds of Defense: Rules at Runtime, Judgment in the Model

Google’s secure-agent approach divides defense into two complementary jobs: deterministic controls that can stop or constrain an action, and model-based defenses that can interpret context and recognize manipulation. This chapter compares those jobs at the point where an agent proposes a tool call. The reader should be able to decide when an action needs an external allow, block, or confirmation decision, when contextual model analysis adds value, and why better instruction following still cannot serve as the entire security boundary.

Runtime policy is the dependable stop before impact

A runtime policy engine sits outside the agent’s reasoning process. When the agent proposes an action—sending an email, purchasing an item, changing a setting, or calling another tool—the request is intercepted before execution. The policy engine evaluates properties such as the action’s inherent risk, the current context, and potentially the chain of earlier actions. It can then allow the operation, block it, or require explicit user confirmation.

That placement gives the policy engine a distinct security role. The model may believe that sending a message is the right next step, but the policy engine can still ask whether the message goes outside the organization, whether it contains sensitive information, or whether the agent has just processed a suspicious source. A purchase policy might block an amount above a limit and ask the user to approve an intermediate range. Google presents those spending values as examples, not universal thresholds. The important mechanism is the external decision point, not any particular number.

A policy can also use action history. An external email may be ordinary in one workflow and risky immediately after an agent has read an untrusted document. The policy does not need to understand every sentence in the document to enforce a narrower rule: under this combination of action, destination, data sensitivity, and recent context, pause or deny the side effect. That creates a hard boundary around the consequence even if the reasoning core has been manipulated.

Deterministic enforcement has four practical strengths. Its outcome is predictable for a defined condition. It can be tested against known cases. It can be audited after the fact. And it can directly limit the worst-case impact of a malfunctioning or compromised agent. These properties make it appropriate for critical or irreversible actions where “the model usually gets it right” is not a sufficient guarantee.

The same strength creates a limitation. A rule can reliably enforce the wrong decision when its condition does not capture the meaning of the task. Sending an email after reading a document can be a legitimate summary workflow or an exfiltration attempt. A policy that blocks every such action reduces one risk but also removes useful autonomy. A policy that allows every such action preserves convenience but assumes that the model can always tell the difference. In a large action ecosystem, writing comprehensive rules is difficult, and static conditions may miss a harmful case that policy authors did not anticipate.