Read it in 10 minutes

This page is a map of the map: what the report argues, the terms it leans on, and where each open problem lives on this site, one paragraph per area with a link to the full explanation.

What the report is

Open and Emergent Problems in Agentic Privacy and Security: A Contextual Angle (Bagdasarian, Tsai et al.) is the written output of the Google Contextual Agent Privacy and Security (CAPS) Workshop, held in New York City in November 2025. The executive summary describes it as a synthesis of deliberations among "more than 30 academic and industry leaders" at the workshop, plus follow-up discussions (Executive Summary, p. 2).

It is organized in three parts. Part I (§1–§6) sets up the problem and the frame. Part II (§7–§9) looks at the three layers where defenses can live: the system around the model, the model itself, and the user. Part III (§10–§12) zooms out to evaluation, multi-agent ecosystems and governance. §14 is a numbered list of every open problem with its page (§14, p. 77). The 51 break down as 3 in §5, 7 in §6, 11 in §7, 4 in §8, 6 in §9, 7 in §10, 9 in §11 and 4 in §12.

The core claim

Agents create a tension the report names early: to be useful with little supervision, an agent seems to need broad access to data and tools, and that cuts against least privilege, data minimization and compartmentalization (§1, p. 7). The report's way out is not "give it less" or "ask the user more." It is to make the agent act appropriately: share what the context calls for, refuse what it does not. Under that view an agent does not have to keep everything secret, which preserves utility, but it also cannot hand over anything it happens to have access to.

The definitions it builds on

An AI agent, for the report, takes unstructured inputs and instructions, generates a plan with a model (usually an LLM), and acts by calling tools or APIs, talking to people, or talking to other agents (§1.1). It may have memory, skills and a sandboxed runtime. An agentic system is any software that uses one or more agents. Then the target:

"A trustworthy agentic system must provide utility while acting appropriately under both benign and adversarial conditions."— the report, §1.1, p. 8

That splits into three properties: utility (do the task reliably), privacy (information-sharing actions stay appropriate) and security (non-information-sharing actions cause no harm). The "benign" half matters. The report wants an agent that does not leak under attack and does not leak through a hallucination or a misread instruction. Safety broadly is declared out of scope (footnote 1, p. 8).

Two more terms recur: system context (memory, skills, knowledge bases, the system prompt) versus model context (what is in the window now), and the harness, the code that runs the model and its tools (§2, pp. 10–11). The glossary has the rest.

Why agents break the old playbook: three dimensions

The executive summary gives three reasons conventional engineering struggles here (p. 2):

§3 adds four threat models: malicious users, a malicious environment (indirect prompt injection), a poisoned model, and no adversary at all, where the agent fails through poor judgment or over-eagerness (§3, pp. 12–14). One twist: the report treats an injection as something that can flip the agent's judgment in either direction, so not every injected instruction is harmful. The full treatment is on Three dimensions, four threat models.

Contextual Integrity in one paragraph

CI (Nissenbaum, 2009) says privacy is the appropriate flow of personal information, not secrecy and not individual control (§4.1, p. 15). "Appropriate" means matching the information norms of a social context such as healthcare, education or family life, where contexts are abstract social spheres with roles, purposes and values, not apps or platforms. A flow is described by five parameters: sender, recipient, data subject, attribute (the type of information) and transmission principle (the condition on the flow, such as confidentiality, consent or legal requirement) (§4.1.2, p. 17). User preferences enter through transmission principles like "with consent," but are bounded and can be overridden by context (§4.2). Our reading: CI is useful for agents because it gives a vocabulary for "fine here, not there" that is neither a blanket secret nor a blanket permission. More on Contextual Integrity, applied to agents.

Contextual Security

§5 extends CI past personal data. Contextual Security means enforcing appropriate behaviors of any kind, not only personal data flows, judged against the context's purposes (§5, p. 19). Its sharpest claim is that classic security is morally unbound: a system is "secure" if it enforces whatever boundary its spec chose, whereas the report wants the boundary itself judged against society's norms. Its running example is an agent that, with benign intent, hacked a gym booking site to get its user into classes; on this view both the agent and the gym system were contextually insecure. A contextual security norm is a pair (functionality, security goal) set against a realistic threat model for that context. Three problems, all conceptual: what parameters describe behaviors that are not personal-data flows (OP 5.1), how to settle on a reasonable threat model (OP 5.2), and how to agree on contextual security norms (OP 5.3). See Contextual Security.

Five reasoning steps and the policy engine

§6 asks what an agent must be able to do if it really follows CI, and answers with five steps: identify the information flows or state changes an action causes; find the norms that apply; judge appropriateness; resolve uncertainty (which context, fuzzy matches, conflicts); and enforce by adjusting behavior (§6, p. 23). No model is reliable enough to do all five alone, and users cannot do them at agent scale, so the report proposes an enforcement layer around the model.

It calls that layer a contextual policy engine (p. 26): a policy generator that maps context and norms into a machine-checkable policy over agent actions (escalating to the user when it cannot), and a runtime enforcer that allows, denies, modifies or escalates each proposed action. Keeping it separate from the planner is the point; Conseca, which the report cites, builds its policies only from trusted context so injected text cannot shape them. It surveys many proposed policy systems and says no standard policy language has emerged.

Seven problems: how far to trust models versus users (OP 6.1); whether models can extract norms at all (OP 6.2); how to represent norms (OP 6.3); turning natural-language norms into formal policy (OP 6.4); keeping untrusted context out of policy generation (OP 6.5); precedence between conflicting policies, separating preferences, values and requirements (OP 6.6); and enforcement that scales to many users, loops and policies (OP 6.7). See the policy engine page.

The open problems, area by area

Parts II and III fill in the engine's pieces and the world around it (Part II, p. 30).

§7 Systems: identity, authorization, accounting

Identity protocols assume the actor is a human or deterministic code; an agent is neither (§7.1). The problems: telling agent actions apart from human ones (OP 7.1), tracing an agent's action back through a delegation chain to the user (OP 7.2), authorization that is aware of purpose, not just resource ("only while helping the user find a doctor") (OP 7.3), tying credential lifetime to task lifetime (OP 7.4), and verifiable artifacts that bind an action to the user's original intent (OP 7.5). See Identity, authorization, accounting.

§7.4 Systems: data privacy

The old toolkit (PII redaction, minimization, deletion, anonymity) becomes dynamic. Redacting "CEO" can break the task; PII leaks into reasoning traces and memory (OP 7.6). "Minimal data" is hard to define for a natural-language task, a flat context window spreads data across sub-tasks, and even encrypted traffic shape can leak the task (OP 7.7). Deleting a record does not delete its summaries and embeddings, so the report proposes "functional revocation" (OP 7.8). And anonymity collides with the accountability §7.1 wants (OP 7.9). See PII, minimization, deletion, anonymity.

§7.5 Systems: AI as the last-mile developer

The report's most code-shaped argument: the more "agentic" an app is, the more of its specification the developer hands to the model. Replace each LLM call with a nondeterministic choice and an email-to-calendar app stays bounded, while a general planner becomes exec(*) (§7.5.2, p. 41). Two problems: closing the gap between developer intent and what the app actually permits (OP 7.10), and bringing testing, review and verification back to workflows generated and run in seconds (OP 7.11). See AI as the last-mile developer.

§8 Models: contextual reasoning

Can the model itself judge appropriateness? The report points to RL in simulated, stateful environments rather than supervised fine-tuning alone, and to a "knowing–doing" gap where a model states the right norm and then pastes the API key anyway (OP 8.1). It asks how to resolve ambiguity without nagging the user (OP 8.2), how to detect stale assumptions as life changes (OP 8.3), and how to interpret what private information a model actually used, since reasoning traces are often unfaithful (OP 8.4). See Teaching models contextual reasoning.

§9 Users: mental models, consent, trust

Users cannot predict an agent's steps, tend to treat it like a person, and lose track of what its memory holds (OP 9.1). Notice-and-choice was already shaky; agents make it worse (OP 9.2). Appropriateness has to count bystanders and third parties, not only the user (OP 9.3). The proposed direction is user-set policies with risk-based interruption rather than a prompt per action (OP 9.4). On trust: a "stop" that really stops every sub-agent, plus delay and undo (OP 9.5), and an accountability framework modeled on contracts, transparency, liability and incentives (OP 9.6). See Mental models and the end of notice-and-choice and Trust, stop buttons, accountability.

§10 Evaluations and benchmarks

The report reviews 16 CI benchmarks (Appendix D) and finds three gaps: ambiguity is filtered out, personas are synthetic, and everything is a short single-session snapshot (§10.2, p. 62). Seven problems: why automated red-teaming stopped finding attacks on frontier models (OP 10.1); large-scale user studies on real agent use (OP 10.2); how agents use years of memory (OP 10.3); leakage that accumulates across many runs (OP 10.4); privacy-utility trade-offs that shift over a lifetime (OP 10.5); benchmarks that survive a harness change (OP 10.6); and agents that revisit past sharing when context shifts (OP 10.7). See Evaluations and benchmarks.

§11 Multi-agent ecosystems

When agents meet strangers, they need a "contextual handshake" to agree on roles, data types and transmission principles first (OP 11.1); repeated interaction can produce collusion and norm drift no single agent shows (OP 11.2). Delegation must carry the user's constraints hop to hop (OP 11.3), swarms need auditing individually and collectively (OP 11.4), and two defensible disclosures can combine into a diagnosis (OP 11.5). On channels: protocols like MCP and A2A carry free-form language and enforce no policy (OP 11.6); attestation proves which code runs, not how it will behave (OP 11.7); constraining the inter-agent language trades utility for safety and pushes leaks into side channels (OP 11.8); and realistic multi-agent simulation environments are still missing (OP 11.9) (§11, pp. 65–72). See Shared norms, delegation, composition and Protocols, attestation, side channels.

§12 Governance

Whose norms, and who checks? The report asks what conditions make contextual privacy achievable, such as incentives for developers and extending "reasonable expectation of privacy" beyond the state-versus-citizen relationship (OP 12.1). It sketches three routes to sourcing norms: top-down baselines, empirical discovery feeding a public norm repository, and agents that run the CI heuristic themselves (OP 12.2). Agents cross jurisdictions within a single session, so conflicting norms are routine (OP 12.3), and compliance has to be verifiable at the moment the agent acts, not reconstructed months later (OP 12.4) (§12, pp. 72–75). See Governance.

What the report does not claim

Read it as an agenda, not a findings paper. Three things to keep straight:

• It proposes no policies. On governance it is explicit:

"Proposing specific policies is beyond the scope of this manuscript."— the report, §12, p. 72

• It is a call to action. The executive summary and conclusion both frame the goal as creating awareness and getting academia, government and industry to work on these problems (pp. 2, 76).
• Most directions are untested. Systems it names (Conseca, CaMeL, AirGapAgent, Progent, Macaroons, GNAP and others) are prior work it points to, often not built or evaluated for agents; it says outright that trust-management systems like Macaroons and SPKI/SDSI have not been applied to agents (§7.2). Even its central policy engine comes with the caveat that the "ideal" architecture is itself open (Figure 2, p. 27). Our reading: treat every "could" and "might" in the report as a hypothesis worth testing, not a recommendation.

Where to go next

• For builders — what this means if you are shipping an agent next quarter.
• Glossary — CI-tuple, transmission principle, system context, policy engine and the rest.
• Contextual Integrity, applied to agents — the frame, properly.
• Three dimensions, four threat models — why the old toolkit strains.
• The contextual policy engine — the architecture most of Part II hangs off.
• All 51 problems on one page — the map's index.

Connections

The report's own spine runs §4 → §5 → §6 → Part II: CI gives the vocabulary, Contextual Security widens it to actions, and §6 turns it into an architecture whose pieces are systems, models and users. Stale context is a thread that runs from OP 8.3 into OP 10.3; for a worked benchmark on agent memory, the sibling CIMemories field map is related reading.

Further reading, verified

• Open and Emergent Problems in Agentic Privacy and Security: A Contextual Angle — Bagdasarian, Tsai et al. (2026) · the publication page; the PDF is the canonical source.
• Contextual Agent Security: A Policy for Every Purpose — Tsai & Bagdasarian (2025) · Conseca, the report's main example of policy generation isolated from untrusted input.
• AirGapAgent: Protecting Privacy-Conscious Conversational Agents — Bagdasarian et al. (2024) · cited for "share data appropriately" and for separating data selection from task execution.
• Defeating Prompt Injections by Design — Debenedetti et al. (2025) · CaMeL, cited for isolating a trusted planner from untrusted data.
• Can LLMs Keep a Secret? Testing Privacy Implications of Language Models via Contextual Integrity Theory — Mireshghallah et al. (2024) · cited as evidence that commercial models reveal information in contexts people would consider inappropriate.