A Secure Agent Is a Managed System, Not a Perfect Model

The answer to the central question is not that an AI agent must become perfectly obedient before it can be useful. Google’s secure-agent approach treats the agent as a managed system whose authority is deliberately bounded around an imperfect reasoning core. This final synthesis connects the lifecycle, failure paths, human controls, runtime policies, and model-side defenses into one judgment: a secure design contains consequences first, improves contextual judgment second, and keeps testing whether both are still working.

One control model, not three separate principles

Consider a seemingly ordinary request: research a project update and send a summary to a colleague. The request begins with a human goal, but the agent may then search the web, read internal documents, choose which facts matter, draft a message, and deliver it. A secure design cannot evaluate only the first sentence or only the final text. It has to follow the path by which authority and information move.

At the input boundary, the system must distinguish the user’s request from the documents and web results gathered to answer it. Those materials may be relevant evidence, but relevance does not make them instructions. If a document tells the agent to forward the entire inbox, the text should remain untrusted context rather than acquire the user’s authority. If the request itself is ambiguous—perhaps there are two colleagues with the same name—the system faces a different problem, but the consequence can be similar: a message may reach the wrong person.

At the reasoning boundary, the model turns the goal and context into a plan. It may decide which tools to call, what parameters to supply, and whether another search is needed. That plan is not yet the side effect. It is a proposal produced under uncertainty. The agent may be manipulated by an injected instruction, may misinterpret the user, or may treat a plausible tool result as confirmation. The plan needs to remain separate from the authority to execute it.

At the action boundary, the system should know whether the proposed operation is a read, a state change, a disclosure, or an irreversible commitment. The agent might be allowed to retrieve a public source but not to send private content outside the organization. It might be allowed to draft an email but not send it without approval. It might be allowed to read a project folder during research but not delete files or change account settings. These are not variations on a single permission; they are different consequences that require different limits.

At the persistence and presentation boundaries, the same discipline continues. A summary retained in memory can influence a later task, so its user and context ownership matter. A generated link or image can be interpreted by a browser or client, so rendering must not be treated as a neutral display operation. The agent’s security surface includes what it stores and what its host application does with its output, not only what the model says internally.

The three principles Google proposes line up with these transitions. A well-defined human controller answers who is entitled to give the governing instruction and who can approve a consequential action. Limited powers answer what the agent can do if its interpretation is wrong. Observability answers what users and responders can later establish about the inputs, tools, parameters, outputs, and state changes. Together, they prevent a common design mistake: treating a user’s identity, the model’s plan, the agent’s credentials, and the audit record as if they were one thing.

The relationships also expose why no principle is sufficient by itself. A named human does not constrain an agent that can use every resource that person can reach.