EU Forces Google to Open Android’s Sensors to AI Rivals

Authors: Cloud Security Alliance AI Safety Initiative
Published: 2026-07-18

Categories: Identity and Access Management
Download PDF

Key Takeaways

  • On July 16, 2026, the European Commission issued binding specification decisions ordering Google to give competing AI assistants the same access to Android’s microphone, camera, screen contents, and background automation capabilities that Google currently reserves for its own Gemini assistant [1][2].
  • The mandate covers eleven distinct Android features, split between six capabilities third parties can access without prior certification and five higher-risk capabilities gated behind a forthcoming Qualified AI Assistant Programme [1].
  • Google must ship the interoperability changes no later than Android 18, with a hard deadline of August 1, 2027; the Commission has set interim milestones in February and May 2027 for certification terms to be finalized [1][3].
  • Google has publicly objected that the order “threatens device security by granting external apps sensitive and powerful device permissions,” arguing it removes the vetting role device manufacturers currently play [1][4].
  • CSA’s assessment: the decision converts a platform-level security boundary into a regulatory-mandated multi-tenant trust problem — any certified assistant will be able to request always-on audio, continuous camera and screen capture, and synthetic input across other apps, expanding Android’s effective attack surface regardless of which vendor exploits it.

Background

The European Commission’s action stems from specification proceedings opened against Alphabet on January 27, 2026, under the Digital Markets Act (DMA), the EU’s competition framework for regulating “gatekeeper” platforms [2][3]. The Commission had already designated Android and Google Search as core platform services subject to DMA interoperability obligations; the July 16 decisions apply those obligations specifically to the AI assistant layer that Google has built on top of Android, principally Gemini [2]. A companion decision addresses a related complaint: that Google’s exclusive access to Search query, click, and ranking data gives its own AI products an unreplicable advantage over competing search-enabled chatbots. Google must begin sharing anonymized Search data with eligible third parties, including AI chatbot providers, starting in January 2027, using a multi-layered anonymization method the Commission says it developed with privacy experts and aligned to draft EU joint guidance on the DMA-GDPR interplay [2][3].

In CSA’s assessment, the Android decision is the more consequential of the two from a security standpoint because it does not merely open a data feed; it opens device-level control surfaces. According to reporting on the decision, Google must expose eleven Android features to certified rival assistants, divided into two tiers [1]. The first tier, available without case-by-case certification review, includes continuous background access to the microphone, system audio, camera feed, and on-screen content; always-on hotword detection running on a low-power digital signal processor that survives a locked screen; long-press invocation; access to system-level on-device models; the ability to run a third party’s own model implementation; and background execution rights. The second tier, gated behind certification, includes centralized access to opt-in application data through Android’s AppSearch index, context-aware proactive suggestion capabilities, structured integration with App Actions and Functions, screen automation equivalent to computer-control agents, and system-level integration covering settings, media controls, screenshots, and notifications. Combined, these tier-two capabilities would let a certified assistant manage a user’s Gmail, Calendar, Drive, Maps, YouTube, SMS/MMS/RCS messaging, and phone calls on the device [1].

Eligibility is not unlimited, but the specifics reported so far apply to a different program than the one this decision governs. The Commission has not published a minimum-user-count or eligibility threshold specific to Android assistant certification; a 50,000-monthly-EU-user floor, sanctions exclusion, and high-risk-country exclusion reported alongside this decision apply to the companion Search data-sharing obligation described above, not to the Android certification program [1]. What the Commission has specified for Android is procedural: Google is required to establish a Qualified AI Assistant Programme with free certification testing covering user intent confirmation, data-disclosure minimization, mobile application security, and hardening against agentic risks, and to designate Trusted Certification Authorities to administer it — though Google itself cannot revoke a certified assistant’s status arbitrarily once granted [1]. The Commission’s own announcement frames the security posture in general terms, stating that the measures include “robust safeguards to ensure that the privacy of users, device integrity and security are protected,” and that Google retains the ability to assess, before any data sharing occurs, whether a specific third party poses a serious cybersecurity or data protection risk [3]. Reported implementation detail adds that consent must gate all sensor access using the same prompts Google’s own services use today, that process isolation and encryption are permitted as compensating controls, that input validation is required to address agentic risk, and that app developers can mark sensitive views as off-limits to automation [1]. Google must give the Commission four weeks’ notice before applying any platform integrity measure that could affect how certified assistants operate [1].

Google’s public response has centered on the security trade-off. Kent Walker, the company’s president of global affairs, said the Android decision “threatens device security by granting external apps sensitive and powerful device permissions,” and pointed to the current model — in which device manufacturers vet which assistants get privileged system access — as a safeguard the decision effectively dismantles [1][4]. Google separately raised concerns about the adequacy of the Search data anonymization method and about national-security implications of broader data sharing [4]. Users will not see practical changes until the next major Android release ships, expected around mid-2027, with full multi-assistant concurrent hotword detection not required until August 2028 [1].

Security Analysis

The core security question raised by this mandate is not whether any single rival assistant is trustworthy, but whether Android’s permission model can safely scale to an arbitrary number of certified, sensor-privileged agents operating with background execution rights. Android’s existing permission architecture assumes a small number of high-trust, platform-integrated actors requesting sensitive capabilities such as always-listening hotword detection or screen-content capture; extending that same privilege tier to a growing roster of third-party assistants multiplies the number of independently developed, independently secured codebases that can observe a user’s microphone, camera, and screen or synthesize input into other applications. Each additional certified assistant is a new potential point of compromise, and unlike a single-vendor model, a security failure in one certified assistant does not stay contained to that vendor’s ecosystem — camera, microphone, and screen capture are device primitives, not per-vendor sandboxes, so a flaw in how one assistant handles a granted capability can expose the same underlying data streams other assistants also touch.

In CSA’s assessment, the tier-two capabilities are the more acute concern because they combine sensing with acting. Screen automation described as equivalent to “computer control,” paired with the ability to imitate taps and typing in other applications, effectively grants a certified assistant accessibility-style control over the entire device. Android’s accessibility APIs, which offer comparable capabilities, have been widely documented as a frequently abused permission class in mobile malware, precisely because they combine broad visibility with the ability to act autonomously on a user’s behalf. Layering a natural-language-driven AI agent on top of that capability class introduces a further failure mode: prompt injection. A certified assistant with screen-reading and screen-automation rights that ingests untrusted on-screen content (a malicious webpage, a manipulated document, an adversarial message) could be manipulated into taking actions the user never intended, including actions inside other, unrelated applications the assistant was never meant to touch. The decision’s requirement for “input validation” to address “agentic risk hardening” acknowledges this category of threat exists, but validation requirements imposed through a regulatory certification process are only as strong as the testing regime behind them, and the Commission’s own summary of the decision does not specify technical criteria for what constitutes adequate hardening [1][3].

The certification model itself introduces a second-order risk: assurance without enforcement. Google is required to build the certification program and select Trusted Certification Authorities but is simultaneously barred from unilaterally revoking a certified assistant’s access once granted, and must give the Commission a month’s notice before applying integrity measures that might restrict misbehaving assistants [1]. That combination — mandatory access grants, constrained revocation authority, and a notice-and-delay requirement before defensive action — creates a structural lag between the discovery of a security or privacy problem in a certified assistant and Google’s ability to act on it at the platform level. In conventional Zero Trust terms, this is a policy enforcement point being told it cannot always enforce its own policy in real time. Because the Commission has not published a minimum-user threshold or vendor-maturity bar specific to Android assistant certification, the pool of certified assistants could plausibly include mid-sized players whose security engineering maturity has not been independently assessed, widening the range of code quality and incident-response capacity operating with camera, microphone, and screen-level trust.

Finally, the aggregation risk deserves attention independent of any single vendor’s intentions. A certified assistant with legitimate access to AppSearch data, context-aware suggestions, Gmail, Calendar, Drive, Maps, and messaging, combined with continuous microphone and camera access, is positioned to build a persistent, cross-application behavioral profile of the user that no single app on Android has historically been permitted to construct. This is a textbook instance of the shadow access problem CSA has documented in AI deployments more broadly: access rights granted for a stated purpose (compete with Gemini on voice assistant tasks) create a de facto data-aggregation capability well beyond that purpose, and the burden falls on consent screens and after-the-fact certification review to prevent misuse rather than on architectural limits to what any one assistant can request at once.

Recommendations

Immediate Actions

Enterprises that manage Android fleets through mobile device management should begin inventorying which AI assistants, if any, employees have installed or are likely to install once certified alternatives to Gemini become available, and should treat “AI assistant with sensor and automation permissions” as a distinct managed-application category rather than folding it into general app allowlisting. Security teams should also review existing mobile application management policies to confirm they can technically block or restrict background microphone, camera, and screen-capture permissions for third-party assistants on corporate-owned and BYOD devices, since the DMA mandate governs what Google must permit at the platform level, not what an enterprise must tolerate on its own managed fleet.

Short-Term Mitigations

Organizations should require any AI assistant seeking tier-two capabilities (App Actions integration, screen automation, system-level control) to pass an internal security review beyond whatever certification the EU’s Qualified AI Assistant Programme provides, given that the programme’s stated testing scope covers general categories such as data-disclosure minimization and agentic-risk hardening without published technical benchmarks. Where possible, security teams should apply context-based access control principles to govern which of a device’s capabilities an assistant can invoke under which conditions, rather than granting broad standing permissions at install time, and should monitor for anomalous automation activity (unexpected app-switching, synthetic input events, unusual data egress) as a detection layer independent of whatever consent gates the assistant itself presents to the user.

Strategic Considerations

Over the next 12 to 18 months, as Google finalizes certification terms in February and May 2027 ahead of the Android 18 rollout, CSA member organizations with a stake in mobile platform security — device manufacturers, MDM vendors, enterprise security teams — have a window to engage with the Trusted Certification Authorities process and advocate for verifiable, technically specific hardening requirements rather than self-attested compliance. This case may be a preview of a broader pattern: as other regulators consider similar interoperability mandates aimed at AI competition, security architecture decisions long made unilaterally by platform owners could increasingly become subject to negotiated, multi-stakeholder, and legally enforced outcomes. Enterprises and vendors should watch for this dynamic — regulatory interoperability requirements colliding with platform security models — extending into other mobile, browser, and cloud ecosystems, and should build governance processes now that can evaluate a newly mandated integration path on security merits within compressed regulatory timelines.

CSA Resource Alignment

This mandate is best understood through the lens of CSA’s Confronting Shadow Access Risks: Considerations for Zero Trust and Artificial Intelligence Deployments, which examines exactly the pattern this decision creates at platform scale: access granted for a defined purpose that enables AI systems to aggregate data and capabilities well beyond that purpose, bypassing the access controls an organization believes it has in place. The report’s framing of Shadow Access — unauthorized access and data exposure arising from AI systems’ complexity — applies directly to enterprises that must now track which certified assistants have been granted camera, microphone, and cross-application permissions on managed devices.

CSA’s Zero Trust Principles and Guidance for IAM is directly relevant to the certification and consent model the Commission has mandated: the guidance’s core argument — that binary, standing-trust access decisions should be replaced with continuous, risk-based, contextual authorization — is precisely what is missing from a model in which a certified assistant, once approved, holds broad standing permissions to sensors and background automation rather than being re-evaluated against real-time risk signals.

CSA’s Context-Based Access Control for Zero Trust offers the most concrete technical remedy available to enterprises and device manufacturers responding to this mandate: rather than granting a certified assistant static, all-or-nothing access to the microphone, camera, and screen, CBAC’s model of consuming dynamic contextual signals — such as user behavior, device posture, location, and network conditions — to drive real-time, risk-based access decisions could be applied at the OS or MDM layer to constrain when and under what conditions a certified third-party assistant’s sensor and automation permissions are actually active, reducing the standing attack surface this decision otherwise creates by default.

References

[1] The Hacker News. “E.U. Orders Google to Open Android Mic, Camera and Screen to Rival AI Assistants.” The Hacker News, July 17, 2026.

[2] European Commission. “Commission provides guidance to Google for AI interoperability on Android and sharing of Google Search data under the Digital Markets Act.” Digital Markets Act (DMA) Portal, July 16, 2026.

[3] European Commission. “Commission provides guidance to Google for AI interoperability on Android and sharing of Google Search data under the Digital Markets Act.” Shaping Europe’s Digital Future, July 16, 2026.

[4] CNBC. “Google required to open up to AI, search engine rivals under EU-mandated changes.” CNBC, July 16, 2026.

← Back to Research Index