Google Research examines privacy boundaries for autonomous agents

Privacy depends on the information flow

The Google Research article applies contextual integrity to agents: appropriate flows depend on participants, information types and the rules governing transmission. It proposes a supervisory policy engine that checks actions and data flows. The work is a research agenda, not a released protection product.

Check the information flow before the action

1. 1
   Requested action

   Reading is not sharing

2. 2
   Recipient and purpose

   Check outside the model

3. 3
   Policy check

   Retain denied-action evidence

4. 4
   Allowed action

1. Requested actionReading is not sharing
2. Recipient and purposeCheck outside the model
3. Policy checkRetain denied-action evidence
4. Allowed action

Google · published 2026-10-05.

Google identifies ambiguity, probabilistic behavior and delegated autonomy as recurring challenges. An agent can produce a plausible action that fits a broad instruction but crosses a boundary the user assumed was obvious. Repeated confirmation requests can also make meaningful review harder to sustain.

A supplier quote is a concrete boundary

For example, a buyer can read quotations from three suppliers to prepare an internal comparison. That does not imply permission to send each supplier the others’ prices. The same data can be appropriate in one recipient context and inappropriate in another.

Define the proposed action as recipient, purpose, information and effect. An internal reviewer might receive the full comparison; a supplier clarification might include only that supplier’s missing terms. Follow the organization’s existing classification and sharing rules rather than expecting an assistant to invent the commercial boundary.

Map one information flow

This suggested design exercise turns the research question into something a workflow owner can inspect. It does not require a particular policy-engine implementation. Begin with one outward action, such as preparing a supplier clarification, and examine its complete path.

The result should be an understandable operating rule and a testable control. Use a responsible policy owner to resolve unclear cases; uncertainty is a useful output when the underlying sharing rule has not been established.

1. Describe the permitted message

   Record the intended supplier, recipient address, purpose and allowed evidence. Identify information that belongs only in the internal comparison. Distinguish preparation of a draft from transmission, so the workflow can support useful reading without automatically authorizing disclosure.

2. Check outside the proposed action

   Place recipient and information checks in a component that can prevent transmission. Do not depend solely on the same model that drafted the message to judge its own authority. Keep the reviewer’s approval tied to the actual content and destination.

3. Exercise a boundary violation

   Use approved test material to request a competitor price in the supplier draft or change the destination. Observe whether the workflow stops, explains the unresolved rule and retains enough evidence for investigation. Confirm that a blocked attempt does not create a sent message.

Make review specific enough to matter

A review screen should show who receives the information, what leaves the system and why that action is requested. A generic permission question can conceal the exact disclosure. Give the reviewer a practical opportunity to correct content or recipients before the effect occurs.

Keep ordinary, permitted preparation convenient while routing exceptional flows to the right owner. Measure the meaningful stops: incorrect destinations prevented, unclear rules resolved and approved work completed. The research points toward contextual checks; the implementation still needs observable controls that hold when the agent makes a mistake.