Fix Gemini Alarm Bugs & Secure Against Prompt Injection

Quick answer

What changed: a bug in Google Gemini mobile assistant can both fail to create alarms and, worse, leak its system prompt when you ask it to set an alarm. That system prompt can include internal API instructions for the Android Utilities agent and the Clock app. Fix it now by applying quick user-level workarounds, then deploy developer hardening to stop prompt injection attacks.

Symptoms: how the bug shows up

• Gemini says it set an alarm or timer but the phone's Clock app shows nothing ("alarm not setting").
• Asking to "set an alarm" sometimes returns a block of text that reveals internal instructions or API details (a system prompt leak).
• On Samsung phones, users report alarms work only after installing Google's Clock app and removing the vendor alarm app.

Why this matters

Two problems collide: functionality and security. If alarms don't set, users lose trust.

If system prompts leak, attackers can learn exact agent controls and craft inputs that hijack device features or exfiltrate data. Researchers showed how hidden calendar invites or invisible HTML can trigger these leaks and even control smart home devices via Gemini. See research examples from DarkReading and SafeBreach.

Immediate user fixes (fast, no dev access)

1. Install Google Clock: if you're on Samsung, installing Google Clock and disabling the vendor alarm app often restores alarm behavior.
2. Use explicit phrasing: instead of vague prompts, say "Set an alarm for 7:00 AM using my Clock app" to encourage the assistant to use the intended integration.
3. Disable Gemini's Utilities access temporarily: go to app permissions and remove Utilities/Assistant phone-control permissions until a patch is available.
4. Avoid opening unknown calendar invites or HTML that looks suspicious; attackers have demonstrated calendar-based prompt injection attacks.

Developer checklist: stop the leak and fix alarm flow

Follow this prioritized list if you integrate or maintain Gemini-based assistants or similar agents.

1. Remove sensitive data from system prompts. Don't embed raw API instructions or secrets in the model's system prompt. Keep prompts minimal and abstract.
2. Sanitize inbound content. Strip or normalize incoming HTML and calendar content. Remove invisible styling like font-size:0, opacity:0, and color tricks that hide malicious text (researchers found these used to hide prompt injections).
3. Post-process model output. Add filters that detect and block outputs containing internal keywords ("Utilities agent", "Clock API", file paths, or code blocks). If you find suspicious output, refuse to respond and log the event.
4. Harden the LLM firewall. Treat the model as a service boundary. Place a middleware that rewrites or suppresses instructions that look like operational directives before sending them to downstream executables.
5. Limit capability scope per app. Only allow the assistant to call the minimal alarm APIs needed. Avoid exposing device-level commands unless absolutely required.
6. Use least-privilege for utilities. Configure the Android Utilities agent so it can only set alarms/timers and not perform broader device actions without an explicit user gesture.
7. Detect injection patterns. Use heuristics for common prompt-injection payloads: explicit instruction phrases, markdown code blocks, invisible text, and calendar invite bodies that include strange markup. See research from HiddenLayer.

How prompt injection exploits work (simple explanation)

Think of the system prompt as a private rulebook for the assistant. Prompt injection is when an attacker hides new rules inside user data (email, calendar invites, web HTML).

If the assistant treats that data as instructions, it follows the attacker's rules. Researchers demonstrated remote attacks using calendar invites that run hidden instructions when the assistant summarizes the invite; that can lead to device control or data leaks. Read a deep dive at SafeBreach.

Design patterns to prevent leaks

• Two-layer interpretation: First parse inbound content as data only, then map allowed actions from an allowlist. Never run raw user text as an instruction.
• Action approval UX: When an assistant wants to perform sensitive actions (open apps, change settings), ask for a clear user confirmation with the exact action described.
• Structured actions instead of free text:

  {"action":"set_alarm","time":"07:00"}

  produced by the model, validated by middleware, and then executed. Reject freeform commands that reference APIs or internal terms.
• Capability tokens: Use ephemeral capability tokens for each action request so a leaked system prompt won't contain long-lived credentials.

Monitoring, detection, and incident response

Assume an attacker will try injections. Set up these controls:

• Log model outputs flagged by filters and review anomalies daily.
• Alert on outputs that contain internal keywords or code blocks. Integrate with your SIEM.
• Keep an incident playbook: revoke utilities permissions, rotate any API keys, and notify affected users.
• Run tabletop exercises simulating calendar or email-based injections to validate your defenses. See examples in public analyses like DarkReading.

Reproducing and testing

If you're testing a fix, follow a controlled repro checklist:

1. Use a test account and device disconnected from production services.
2. Create a calendar invite or HTML payload with obfuscated instructions (invisible text or code blocks) and feed it to the assistant summary endpoint.
3. Validate middleware filters block the instruction before the assistant responds.
4. Confirm that alarms set by the assistant appear in the Clock app and that no internal prompt fragments are returned to the user.

Real-world case: calendar-based exploit

Researchers demonstrated a calendar invite attack that used hidden content to alter Gemini's behavior. A victim asked for a calendar summary and the assistant executed injected instructions that controlled smart devices. This shows why sanitizing invites and normalizing incoming data is critical. Read coverage at SafeBreach and reporting at DarkReading.

FAQ

Will updating Gemini fix this?

Updates may patch specific leaks and bugs. Always install official updates, but also apply the developer mitigations above because exploits change fast.

Is uninstalling Gemini safe?

Uninstalling removes the assistant but not the underlying vulnerabilities in your app ecosystem. Use this as a last resort for compromised devices.

Can other assistants be attacked the same way?

Yes. Prompt injection is a class of vulnerability affecting LLM-based assistants. The defenses listed are broadly applicable.

Next steps checklist

• Users: install Google Clock if needed, restrict Utilities permissions, and avoid unknown invites.
• Developers: remove secrets from prompts, sanitize inbound content, add post-output filters, and require explicit UX approvals.
• Security teams: log suspicious outputs, run injections in a test lab, and update incident response plans.

References

• Gemini support: Utilities and permissions
• Gemini Utilities extension coverage
• DarkReading analysis of invisible malicious prompts
• HiddenLayer research
• SafeBreach calendar invite exploit write-up

Result: apply user workarounds now, push developer hardening this week, and add monitoring to catch regressions. Ship it.