The Google Research team published the results of the Contextual Agent Privacy and Security (CAPS) Workshop — a blog post and a fully open technical report in which the security of LLM agents is for the first time formulated as a separate research discipline with an explicit list of open problems. The main conclusion: conventional static permissions and pop-up consents do not scale to probabilistic agents, and instead 'contextual security' is proposed — an assessment of the appropriateness of each agent action in context before its execution.
What happened
On October 5, 2026, a publication with the results of the Contextual Agent Privacy and Security (CAPS) Workshop, which took place in New York in November 2025, appeared on the Google Research blog. The meeting brought together more than 50 researchers from Google, Cornell Tech, UC Berkeley, University of Washington, Columbia, and other organizations; the final technical report was prepared by about 60 authors under the leadership of Eugene Bagdasarian and Marco Gruteser, and it is available for public access in PDF format. The authors claim that LLM agents break traditional security engineering in three dimensions: plans in natural language are non-deterministic and open a surface for prompt injection; execution paths are probabilistic, not deterministic like in ordinary code; finally, an agent delegates subroutines to other agents, which inevitably gives rise to 'consent fatigue' in the user. As a theoretical foundation, the report takes the concept of Contextual Integrity by Helen Nissenbaum and extends it from the privacy of information flows to 'contextual security' — the appropriateness of the agent's actions in a specific context.
Context
The classical security model was built around deterministic code: a developer describes in advance what a program does, and a user grants permission once — this is how static permissions work in ordinary services and policy languages like Cedar, CEL, Datalog, and Open Policy Agent. Agents with an LLM planner do not fit into this scheme: what exactly an agent will do is determined at runtime in natural language, and it is impossible to fix all execution trajectories in advance. Hence two known problems: prompt injection, when malicious instructions enter the same channel that controls the agent, and 'consent fatigue' — a state in which pop-up confirmations appear so often that a person clicks 'allow' without looking. Nissenbaum's theory originally described the admissibility of information transfer between contexts; the authors of the report transfer this apparatus from data flows to the actions themselves, adding a formal vocabulary to agent security that it has not had until now. In essence, the document turns a set of disparate incidents with agents into a research discipline: with a language for describing problems and an open list of tasks for future work.
Why this matters for the industry
For teams building agentic systems, the report is in fact a roadmap of where Google's security architectures and adjacent research are shifting. The central architectural thesis: the assessment of appropriateness needs to be moved to a separate contextual policy engine from the planner, which before executing an action generates machine-readable policies online and decides — to let the action pass, modify it, block it, or escalate the decision to the user. Such an engine is designed as an evolution of existing approaches based on policy languages Cedar, CEL, Datalog, and Open Policy Agent, but on top of a probabilistic planner, not deterministic code. The report also records a list of unresolved research problems — prompt injection, sandboxing of dynamic plans, emergent behavior of multi-agent systems, — which are already referenced by academic and industrial works of 2025–2026, so teams should check their architectures against this list, rather than building permission models that do not scale to agents. The real impact so far is at the level of design decisions: to separate guardrails from the planner, to log the context of agent actions, and to design escalation to the user as a separate interface channel, not a side effect of permission dialogs.
Why this matters for users
If you use coding agents, browsing assistants, or any tools that act on your behalf, the report explains why endless pop-ups 'allow?' do not protect you: with a stream of such dialogs, 'consent fatigue' sets in, a person confirms without looking — including at the moment when the agent is doing something truly dangerous. The proposed replacement is an engine that before execution itself assesses the appropriateness of the action in context: for example, a shopping list is appropriate to pass to a shopping assistant, but not to relatives, and consent is requested only where the context is ambiguous. It is important to understand that this is a vision, not an available feature: a research document has been published, and today the behavior of products has not changed. The practical benefit for the reader is in the report itself, which is open in PDF: it can be used to check your scenarios — to estimate how many consent dialogs your agent actually receives, whether the habit of confirming mechanically has already set in, and which of the described breakdowns apply to your situation.
What is still unknown / limitations
This is a position research document, not a working system: in the presented materials there is not a single measurement — there is no attack success rate against prompt injection, frequencies of false permissions and blocks of the engine, data on delay, API, and pricing. There are no benchmarks of behavior appropriateness yet: the corresponding section of the technical report (§10) is explicitly marked as an open question. The question of protecting the contextual policy engine itself is also unresolved: without empirical verification, it remains unknown whether the engine is resistant to manipulation of the very context on the basis of which it considers an action 'appropriate'. Therefore, interpretations of the report as a ready-made blueprint for a new product layer or a point of immediate integration are premature: the real impact of the document so far is limited to terminology, a map of open problems, and design decisions, and the scenarios voiced for the coming years are expectations, not confirmed facts.
Sources
- Open and Emergent Problems in Agentic Privacy and Security: A Contextual Angle — Google Research blog
- Open and Emergent Problems in Agentic Privacy and Security: A Contextual Angle — technical report, Google Research Publications
Author
Look at AI, editorial team