RFC: context-boundary validation — provenance for untrusted tool/MCP content that can drive tool calls

[UniversePeak]

Problem

ADK assembles the model's context from sources that are effectively untrusted relative to the tool surface it can reach: tool descriptions (including ones pulled from remote MCP servers), tool outputs, session state written by other agents, and instructions loaded at runtime. None of that content carries provenance the framework tracks, so by the time a call reaches the before_tool_callback pipeline in _tool_caller.py, the callback sees the request but has no first-class way to tell what influenced it — a tool result from a low-trust source looks exactly like the developer's own instruction.

This is the documented "context privilege escalation" pattern: untrusted content in the context window steers the model into calling privileged tools it should never have combined (arXiv 2609.01222 verified this against a dozen agent harnesses). #7076 is the same problem class showing up concretely in the resumable-mode dispatch path.

For related work I checked before filing: #6966 screens tool output via ModelArmor but is vendor-specific screening, and #6099 records decisions for audit after the fact. Neither gives callbacks a general notion of where context content came from.

Describe the solution you'd like

A small opt-in boundary layer, not a new enforcement framework:

1. Provenance tags on content entering context — source kind (developer instruction / tool output / MCP server / session state) attached at assembly points ADK already controls (event construction, toolset declarations, state merge).
2. That boundary context made visible to the existing before_tool_callback pipeline and ToolConfirmation, so a callback can ask "were this call's arguments influenced by untrusted sources, and does that source have scope to call this tool?" without re-implementing event archaeology.
3. Default-allow policy; teams that need it can enforce rules like "MCP tool outputs cannot authorize tool X" or require confirmation on cross-boundary escalation.

Impact on your work

Tool/MCP security is the main blocker we hit when arguing for enterprise agent adoption, and the shape of this API matters a lot. The contribution guide asks for an issue first on substantial features, so before building a minimal prototype and adversarial tests: would this fit better as a core contract on the context/event objects, or as a plugin-level capability reusing the existing callback pipeline? I'd rather align on the direction than open a PR against a guess.

[sattyamjjain]

On your direct question: core contract on the context/event objects, not a plugin.

Provenance has to be written at the moment content enters context. A plugin on the callback pipeline can only infer origin after the fact, which is exactly the event archaeology you're trying to avoid, and it can't retrofit a field the core doesn't carry. If the tag isn't attached at assembly, it isn't trustworthy later.

Enforcement is the opposite and belongs in the callback pipeline, default-allow, the way you sketched it. So: provenance in core, policy in plugins.

One addition to the shape. Tag the source kind, but also carry whether the content already crossed a trust boundary on the way in. MCP tool output derived from another tool's output is the case that breaks single-level tagging, and it's the common one once you have more than one agent writing session state.

I've built this boundary in-process in agent-airlock, deny-by-default at the tool function, with unknown args stripped before validation. Different layer from ADK, but the same split holds: origin tracking and policy want to be separate things.