Google Research announced a workshop report on agentic privacy and security on October 5, 2026, arguing that agents need constraints suited to the social context of their tasks. For builders and privacy reviewers deciding what data and tools to expose, it offers a useful design question: which information flows and actions are appropriate for this particular job?
The publication is a research agenda, not a new model or security service. Google says the broader effort involved more than 50 academic and industry contributors. October 5 is the blog announcement date; the report’s original public-release time is not independently established.
The practical analysis below applies that framing to one scheduling task. If the earlier decision is whether to use an agent at all, start with AI Chatbot, Workflow or Agent? Choose by the Task. Here, the question is what a chosen system may learn, share and change.
Define the context before the permission
Contextual integrity treats privacy as information flowing appropriately within a social setting. “Context” here means roles, purposes and expectations—not simply more tokens in a model’s prompt. The Google report extends that lens from information sharing to the appropriateness of actions.
Consider an internal assistant arranging a project-review meeting. Assume the organization has authorized the workflow and relevant calendar access. For this example, free/busy intervals and approved contact addresses are sufficient; unrelated event titles and descriptions are not. These are explicit design assumptions, not universal scheduling rules. No integration or test is being reported.
The earlier AgentSCOPE research paper maps workflows as individual information transfers, using five contextual-integrity attributes. Applied to the calendar-to-planner transfer, those attributes become:
Sender: the calendar service returning a scoped availability result.
Recipient: the scheduling planner; name any external model-processing service separately.
Data subject: each person whose availability is being processed, not just the user who requested the meeting.
Information category: free/busy intervals for the approved scheduling window, excluding event content.
Transmission principle: use the intervals only to arrange this meeting, under the organization’s approved sharing and retention conditions.
For this scheduling task, the permitted flow is calendar availability to an approved planner—not event descriptions to every connected service.
Add a separate action contract: the approved participant roster, scheduling window, permitted invitation fields and whether sending is authorized. A calendar-read permission does not describe any of those limits. Even the same lookup tool, used under the same identity, can return either necessary availability or unnecessary personal detail.
Map each place the data or authority crosses a boundary
The following is a proposed review map. Its evidence column describes what to inspect or test before deployment, not results already obtained. Name the actual service and responsible owner at each boundary; a generic “agent backend” label hides recipients.
Boundary | What could exceed this task | Proposed control | Evidence to seek |
|---|---|---|---|
Calendar retrieval | The response includes unrelated event titles or descriptions. | Use a scoped free/busy endpoint, or filter within the trusted tool service before returning data to the planner. | A field-level response contract and an overbroad-response test case. |
Model request and logs | Unneeded calendar content reaches a hosted model or telemetry service. | List each recipient and its permitted fields; minimize payloads before transmission and redact log content. | The actual data-flow configuration and traces from synthetic fixtures. |
Delegation | A scheduling helper receives the full calendar or passes it onward. | Send only the required intervals and roster entries. Preserve the original task limits; prohibit unapproved onward delegation. | The receiving service’s identity and an explicit handoff contract. |
Invitation send | The agent adds an unapproved attendee or unrelated event content. | Check addresses, time window and body fields immediately before sending. Bind exception approval to the exact action. | An action preview and policy decision matched to the resulting send. |
Resume after a change | A paused task sends using an obsolete roster or expired authority. | Recheck current policy and expiry before the action; hold unresolved changes for the owner. | A stale-policy fixture with an owner-defined expected outcome. |
The important inference is that a clean invitation is insufficient evidence of a private workflow. If unnecessary event descriptions already reached a processing service, removing them from the final message cannot undo that transfer. AgentSCOPE’s intermediate-flow methodology motivates inspecting those earlier boundaries; it does not validate this proposed design or establish any provider’s retention behavior.
Delegation changes the recipient, even when both agents serve the same organization. In this example, a helper that only compares time slots should not inherit calendar-reading or invitation-sending authority merely because the parent has it.
Keep policy meaning separate from runtime enforcement
Section 6.4 of the report separates generating a formal policy from enforcing it at runtime. It also identifies unresolved problems: accurately translating social expectations into rules, keeping harmful context out of policy generation and resolving conflicting policies. A machine-checkable rule can still express the wrong expectation.
Existing tools supply implementation points, not a solution to those open problems. Google’s ADK safety guidance notes that delegated OAuth scopes can be broader than a task requires and describes restrictions based on developer-set tool context. Its before-tool callbacks can inspect arguments and perform authorization checks before execution. Open Policy Agent accepts structured inputs and returns policy decisions; the application remains responsible for enforcement.
For the scheduling design, keep purpose, approved roster, allowed fields, destination rules, delegation limits and policy expiry in application-owned state. The planner may propose a recipient; it must not authoritatively declare that recipient approved. A new name encountered in retrieved content is a reason to check the task, not permission to expand it.
Distinguish three outcomes. Allow a routine action only within owner-approved bounds. Reject an explicit hard-limit violation. Hold a potentially legitimate exception when purpose or recipient identity is unresolved. This proposed split avoids treating every action as a confirmation prompt, while keeping ambiguous authority out of the model’s discretion.
That choice has a practical cost. Narrow field contracts reduce flexibility: a later request to explain why someone is unavailable may need information deliberately withheld from scheduling. Treat that as a different purpose requiring review, rather than silently widening the original task. Conversely, excessive holds can make the assistant unusable; evaluation should count legitimate actions blocked as well as inappropriate transfers.
Evaluate the rule and the execution path separately
A useful acceptance review has two parts. This is a proposed method, not a benchmark result:
Policy meaning: have the responsible owner label allowed, denied and held cases. Include ordinary scheduling, an unexpected attendee, unnecessary event content and a legitimate exception. Check whether the policy reflects those decisions.
Enforcement coverage: use synthetic or explicitly permissioned fixtures to check that retrieval, model requests, delegation, sends and resumed actions encounter the intended controls. Include expired authority and a policy-service timeout; neither should silently become permission.
This separation follows from the decision-versus-enforcement distinction in OPA and the specific execution points documented by ADK. Correct rules do not prove that every path consults them. Comprehensive checking does not prove that the rules capture the right purpose.
Record completion, inappropriate field transfers at each boundary, unauthorized attempts versus completed actions, valid actions blocked, owner escalations, latency and total attempted-run cost. Keep policy and model/harness versions with the results. Use minimized, access-controlled evidence rather than copying full private calendars into traces. Neither the report nor this analysis supplies a universal passing score.
Google’s announcement calls for dynamic, multi-agent “Agent Gym” evaluation environments. It does not announce a released CAPS package that validates these controls. Treat that proposal as a research direction, not an available mitigation.
The immediate deliverable is a purpose-specific record of fields, recipients and permitted actions, with an owner for each unresolved decision. If the team cannot justify a necessary transfer, narrow the task or keep that step human-led before granting more access.
Methodology: This AI-assisted analysis uses Google’s report and announcement, AgentSCOPE’s published methodology, and ADK and OPA documentation checked on October 5, 2026. The scheduling map and evaluation plan are proposed analysis. No hands-on testing, measured mitigation effectiveness or client outcomes are claimed.