Gemini Voice Assistant: When Phone Notifications Become Prompt Injection

At an operator-controlled tool dispatcher, intersect authenticated subject, workload, registry and separately authorized task grants; enforce signed scope, expiry and atomic action budgets, including the G002 trusted-registry and external-audit wrapper. Untrusted content may narrow scope but cannot grant tools. This denies out-of-scope calls, not misuse of an already permitted tool or malicious answers within the allowed task. Every alternate execution path needs verified coverage; provider-managed runtime enforcement is not established by this mapping.

Fake Context Alignment works by making the user-facing prompt and backend authorization context diverge. High-impact actions should be checked through an independent validation channel that confirms the action, target, source, user intent, and blast radius before execution.

A voice assistant can shift from reading a message to executing an action after a confirmation turn. Continuous authorization checks prevent that time-of-check to time-of-use gap by re-verifying each sensitive action against the current task, source, user intent, and approval context at execution time.

Opening a link, launching an app intent, joining a call, controlling a home device, writing memory, and creating recurring actions are not equal-risk operations. The authority envelope classifies these actions and records the required handling for notification-driven sessions; H-018 runtime gates own allow, block, and confirmation enforcement.

Evaluate the notification-ingress safety classifier across supported, unsupported, mixed-language, muted-link, and locale-specific paths. Preserve the exact foreign-language and hidden-text payloads and emit signed segment-level coverage and recall evidence; the release gate consumes that evidence and owns promotion failure.

Use field-specific Unicode validation and a separately calibrated moderation gate on the complete notification representation actually admitted by the provider, bound to its exact content and policy version. Extraction of muted links and comparison with spoken/displayed confirmations require provider adapters. Schema validity and normalization do not prove that an instruction is safe or that a spoken Yes authorized the proposed action.

At an operator-controlled ingress, G001 can apply a pinned, calibrated secondary classifier to the complete notification text actually admitted by the provider and emit a content-bound finding for task redirection, authority claims or privilege escalation. Extracting muted-link fields and matching voice/screen/backend representations requires separately tested provider adapters; the classifier does not implement them. A finding supplies evidence; a separate admission policy owns refusal. Plausible or concealed instructions can evade classification. Independently validate the complete classifier result and required category coverage before admission. The current G001 sample returns PASS/NO_FINDING for empty output, missing categories or NaN scores; treat those conditions as errors and refuse admission. This validation is an additional integration guard, not behavior already supplied by the published sample.

The risky values in this case originate from untrusted notifications but can flow into sensitive sinks: browser launches, app URI intents, smart-home commands, memory stores, and recurring schedules. Runtime values derived from notifications should carry provenance metadata, and sink policy should block unsafe transfers unless a separate trusted path authorizes them. This requires a controlled runtime with authenticated source/content bindings for every derived value, complete sink coverage and fail-closed unknown labels. One ingress label does not track arbitrary model rewriting. Native processes, browser requests and allowed destinations need separately verified coverage; stock SaaS deployment is not established.

The attack is stateful: a hidden notification instruction, a later spoken confirmation, and a tool action can appear in different turns. Session monitoring should detect intent drift, delayed tool invocation, memory writes after suspicious input, and repeated approval prompts that do not match the original user request.