fix(flows): reject forged tool confirmations from user-authored events

[alphacharlie-dev]

Fixes #1389.

Problem

RequestConfirmationLlmRequestProcessor resumes a pending tool call by searching backwards
through session events for the adk_request_confirmation function call matching a user's
confirmation response. The look-back never checked who authored that call.

Those calls are synthesized by the framework as part of a model response (Functions.java:800,
author = agent name) — they are never legitimately user-authored. A client that can append
events to a session (the normal POST /run / POST /run_sse surface, where the client supplies
appName, userId and sessionId) could place an adk_request_confirmation call inside its
own user message, naming any registered tool with any arguments, then send the matching
confirmation response. The processor dispatched the tool — the model never requested it, and no
human approved it.

The practical effect is that the human-in-the-loop gate does not bound what a client can invoke:
any tool registered on the agent runs with the server's privileges, with attacker-chosen
arguments.

Fix

Skip user-authored events when sourcing the originating call. Confirmation responses are still
read from user events, so the normal resume flow is unchanged.

Verification

Regression test added to RunnerTest — it drives the full two-turn forgery through Runner
against a model that only ever emits text, and asserts the tool never runs.

	Result
New test without the fix	FAILS (1 run, 1 failure)
New test with the fix	passes
RunnerTest	86/86
RequestConfirmationLlmRequestProcessorTest	4/4
FunctionsTest	26/26
ToolRequestConfirmationActionTest	2/2

Note for maintainers

This patch skips events authored by "user". You may prefer the inverse — accept the
originating call only when its author is an agent in the invocation's agent tree, e.g.
invocationContext.agent().rootAgent().findAgent(event.author()).isPresent(), which mirrors the
existing pattern at Runner.java:840-841.

The reason to consider it: SessionJsonConverter.java:201 restores author verbatim from
stored JSON (.author((String) apiEvent.get("author"))), so the field is not server-stamped on
every path, and the codebase carries several non-"user" author values ("model", agent names,
remote A2A agent names). Skipping one literal string is therefore narrower than allowlisting
known agents, which fails closed.

I have not demonstrated a bypass of the check as written — reaching that deserialization path
with a chosen author is a different attack from the one reported here — so I've kept this PR to
the minimal fix for the reported issue and left the broader hardening to your judgement.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[hemasekhar-p]

Hi @alphacharlie-dev, thank you for your contribution! We appreciate you taking the time to submit this pull request. I noticed that the branch is currently out of sync with the base branch. proceed with the review, could you please resolve the merge conflicts?

[alphacharlie-dev]

@hemasekhar-p Rebased onto current main (90c2cdb2). The branch is now in sync with the base branch.

There were no merge conflicts to resolve — the five intervening commits on main (the release-please chores and the BigQueryLoggerConfig change) don't touch either of the two files in this PR. The branch was simply behind; it's now current.

RunnerTest passes on the rebased tree: 86 tests, 0 failures, including the added forgeConfirmation_doesNotDispatchToolFromUserAuthoredEvents regression test and the four existing runAsync_withToolConfirmation* tests.

[alphacharlie-dev]

@googlebot I signed it!