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

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.