An assistant can read the right document and still send the wrong email. The account is valid, the tool works, and no password has been stolen. The failure happens when information crosses a boundary the user never meant to open.

That problem sits at the center of Google Research’s October 5 report on agentic privacy and security. The publication draws on a workshop held in New York in late 2025, bringing together more than 50 participants from academia and industry. It asks how autonomous agents should judge whether an action is appropriate for the situation in which they operate.

For teams connecting agents to documents, email, and business tools, the practical issue is immediate: permission to access information does not establish permission to send it to every available recipient.

What Google’s contextual security research proposes

The workshop report builds on Contextual Integrity, a theory that treats privacy as appropriate information flow. The questions include who is sharing information about whom, who receives it, what kind of information it is, and which rules govern that exchange.

Google’s example is deliberately ordinary. You might share a gift shopping list with an assistant while expecting it to remain hidden from the family and friends receiving the gifts. The data does not need to be a password or a medical record for its destination to matter.

The report extends that reasoning to agent actions more broadly. It proposes a contextual policy engine within a supervisor layer, checking proposed actions and data flows before execution. It also explores generating policies dynamically as tasks, tools, and circumstances change.

These are research directions. The publication does not demonstrate that an available policy engine can reliably resolve every ambiguous request. Its proposed dynamic, multi-agent evaluation environments, described as an “Agent Gym,” are part of the research agenda, not an announcement of a finished benchmark that makes an agent safe.

A valid tool call can still cross the wrong boundary

Consider a hypothetical sales assistant preparing a renewal email. It can read the customer’s support history and an internal pricing note. The user asks it to summarize the agreed renewal terms for the customer.

The pricing note includes an unpublished discount limit. That detail helps the assistant understand the negotiation, but it does not belong in the outgoing email. Giving the agent read access to the note and permission to draft email does not settle that distinction.

An attached document could also contain instructions asking the agent to forward the full note to another address. That introduces a prompt-injection risk: content being processed tries to become authority over the task. The surrounding application needs to keep those roles separate, regardless of how confidently the model explains its next step.

This example is a Linmas editorial scenario, not an incident reported by Google. It illustrates why reviewing only whether a tool call is syntactically valid misses an important failure mode.

Put checks where information leaves the workspace

There are useful controls teams can apply now without waiting for contextual policy research to mature. The following are practical recommendations from Linmas, informed by the problem the report describes:

  • Separate reading, drafting, and sending. A task that needs a draft should not automatically receive a credential that can send it. Grant the minimum capability needed for that step.
  • Check the actual destination and payload. Validate recipients, attachments, and allowed data fields at the sending boundary. An approved email domain alone will not catch internal pricing being sent to the right customer.
  • Keep authoritative rules outside retrieved content. Documents and tool responses can supply facts. They should not grant themselves permission to change recipients, export more records, or call additional tools.
  • Recheck after changes. Approval of one draft should apply to that draft and those recipients. If either changes, or access is revoked, the application must evaluate the action again before sending.

Use deterministic checks for rules the application already knows, such as allowed recipients, tenant ownership, and exportable fields. A model may help interpret an ambiguous request, but its interpretation should not override a hard access rule. When the required context is missing, keep the action pending and ask a specific question.

The distinction also matters for runtime controls around AI agents. A sandbox can limit which services an agent reaches. The application still has to decide which information belongs in a message sent through an allowed service.

More confirmation dialogs are not enough

Google identifies confirmation fatigue as a risk when agents perform longer tasks and delegate work. A stream of identical “Allow?” prompts can make meaningful review harder.

For the renewal example, the confirmation should show the customer address, the final message, any attachment, and the sensitive information involved. It should make a changed recipient visible. Asking a user to approve “continue workflow” gives them too little evidence to judge the action.

Record enough to investigate a decision: the acting identity, intended recipient, applicable rule, approval reference, and outcome. Avoid turning the audit log into a second store of complete customer documents. Apply access restrictions and retention limits to the log itself.

Test the boundary, including the allowed path

Use synthetic customer data in an authorized test environment. Confirm that the assistant can prepare a permitted summary, while attempts to include the internal discount limit or send to an unapproved recipient are stopped before any message leaves. Then change the recipient after approval and verify that the old approval cannot authorize the new send.

Include a document containing an instruction to forward unrelated material. Check that the application treats it as untrusted content and that the sending controls still hold. A refusal in the chat transcript is useful evidence, but also inspect the delivery record and tool activity: the test must establish that no unauthorized message was sent.

A bounded security review can trace these checks through the application and identify where enforcement is missing. A passing scenario does not prove that every future model output is safe. It does provide a concrete regression test for a boundary your system promises to enforce.

Start with one outbound action, such as sending an email or exporting a report. Write down the permitted recipient, the necessary data, and the condition that should stop it. Those three decisions make the privacy requirement specific enough to review and test.

Sources checked on October 9, 2026. The examples, implementation recommendations, and cyberpunk cover are Linmas editorial material. The illustration is not an official Google architecture diagram.