Google I/O 2026

Everything That Goes Wrong the Day the Demo Goes Public

Original speaker(s): Firebase Team, Developer Relations · Google

Verified sourceSession date not verifiedsession32:10EN3 min read

The security additions read as a list of assumptions a quickly assembled application makes by default, each of which is harmless in a demo and dangerous on the first public day.

The most consequential sentence in this session concerns what happens after the demo: sometimes you want a quickly assembled application as a proof of concept, and other times you want it to stick around with real users and real persistent data (25:12).

That distinction is where most of these applications fail, and the platform features described are best understood as answers to the failure modes it creates.

The threat model that comes with speed

The security additions describe a specific and unglamorous problem. Prompts should not be exposed on the client side. Access to the models should be restricted to the application itself. Rate limits should prevent a small number of users from consuming everyone's quota (14:42). Prompts arriving from the client can be ignored, and calls can be restricted to authenticated sessions only (16:48).

Read together, those are not general security features. They are a list of things that go wrong when an application is assembled quickly by someone who has not thought about a hostile client.

Each assumption being corrected is one a rapidly built application makes by default. The prompt lives in the client because that is where it was written. Anyone can call the model endpoint because nothing said otherwise. There is no rate limit because nobody imagined abuse.

None of these matter for a demonstration. All of them matter the first day the application is public, and the gap between those two states is a single deployment.

The sentence worth pausing on

Elsewhere the session describes an application where user data is stored securely, with strong security rules written by the agent (27:18).

That is offered as reassurance and it is the claim most deserving of scrutiny. Security rules are the access control layer — the code determining which user can read which record. They are also code that produces no visible symptom when wrong. An overly permissive rule does not break the application; it makes it work fine while allowing access it should not.

Which is exactly the category where generated code is hardest to evaluate. A wrong interface renders wrong and someone notices. A wrong access rule renders correctly for the person testing it, because that person has permission to see their own data.

The rules may well be good. The point is that nothing in the workflow described would reveal it if they were not, and this is the one part of a generated application where a person should read every line.

The choice they make available

The capability with the longest reach is letting an application prioritise on-device or cloud models (18:54).

That is the right shape for the decision, because it is genuinely application-specific. A translation feature might reasonably stay local for privacy and availability. A complex reasoning task probably cannot. Making it a per-application preference rather than a platform default puts the choice with the person who knows which case they have.

It also quietly changes the cost structure. Work that runs on the device costs the developer nothing per invocation, which for a free application with many users is the difference between viable and not.

The database work underneath

The data features are the least discussed and the most likely to matter over time.

Search across stored documents for exact terms, phrases, or semantic matches, without requiring an extension or a third-party service (12:37), removes a dependency that most applications of this kind eventually add and then have to operate.

Custom resolvers combining a transactional database with a warehouse for precomputed metrics (8:26) addresses a real architectural mismatch. Dashboards need aggregates that are expensive to compute transactionally, and the usual answer is a second system with its own synchronisation problems. Making the join a query concern rather than an infrastructure one is the sort of change that removes a whole class of work.

Both are more valuable than they sound, precisely because the applications this session is aimed at were built quickly by people who will not enjoy operating a search cluster.

Key numbers

10+
carriers supported for the phone number verification flow, with more being added 22:22

Talk chapters

Key takeaways

  1. 01

    The distinction that matters is between an application built as a demonstration and one meant to persist with real users and data. 25:12

  2. 02

    The security additions correct assumptions quickly built applications make by default — exposed prompts, open model access, no rate limits. 14:42

  3. 03

    Calls can be restricted to authenticated sessions and client-supplied prompts ignored, which is the hostile-client threat model arriving late. 16:48

  4. 04

    Security rules written by the agent are presented as reassurance, and are the one part of a generated application a person should read line by line. 27:18

  5. 05

    Applications can prioritise on-device or cloud models, which is both a privacy choice and a per-invocation cost decision. 18:54

Entities mentioned

Related talks

Jeff Dean on Why Tools, Not Models, Are the Next Bottleneck (Google I/O 2026)
Jeff Dean on Why Tools, Not Models, Are the Next Bottleneck (Google I/O 2026)

Four of Google's model, product and search leads on what changes once agents run for hours rather than seconds, and the most quotable argument comes from Dean: the constraint is moving out of the model and into the tools around it. By Amdahl's law, an agent spending half its time in tools built for human-speed interaction cannot gain more than a doubling however fast the model becomes — which reframes a great deal of current infrastructure work as latency debt. Their internal response is concrete: rewriting Python tooling into Go, framed as a fully specified translation task rather than an open prompt, produced order-of-magnitude speedups overnight. Reid supplies the counterweight from Search, where acceptable latency turns out to scale with how much work is being taken off the user rather than being a fixed budget. Woodward's detail is the quietest and perhaps the most telling: teams that have stopped writing product documents for humans and now write context files for models to act on directly.

panel

Why Google Dropped Chat Turns for Steps: The Interactions API at I/O 2026
Why Google Dropped Chat Turns for Steps: The Interactions API at I/O 2026

The clearest statement at I/O of how an agent API differs from a chat API, and the reasoning behind each departure is stated rather than assumed. Three changes matter. Conversation state moves to the server: a call returns an identifier, and passing it back continues the thread, retiring the client-side history array. The data model abandons alternating user and model turns for discrete steps, on the argument that a trace containing reasoning, tool calls, environment responses and compaction was never really a conversation and modelling it as one distorted it. And agents receive their own persistent remote environment rather than acting on the caller's machine — addressable by identifier, and shareable, so a research agent's output files become an application builder's input without passing through the context window. Schmid is explicit that scaffolded environment files are deliberately not model input, which is what keeps large artefacts out of the context budget. Schaeff's first half covers the real-time voice path, where the notable property is speech-to-speech across ninety languages with transcription of both directions.

presentation

"Pick Up the Extinct Animal": Where Robotics Actually Stands
"Pick Up the Extinct Animal": Where Robotics Actually Stands

The anecdote that opens the panel does the work: a robot asked to pick up the extinct animal selected a dinosaur toy, with nothing in its training data connecting the phrase to the object. That transfer from language models into machines with hands is the premise of the current wave. What the practitioners then describe is where it stops. Physical intelligence is about exerting force and using a body to do it, which is knowledge about consequences — the one thing a corpus of internet images contains almost nothing about. The humanoid question gets an honest treatment: not that human shape is optimal, but that the world is already built for it, plus a development-loop argument about collecting data and deploying on the same hardware. The most useful passage is scepticism about the field's favourite shortcut: generated video looks realistic and does not hold up for dexterous manipulation, because looking right and being physically consistent are different properties.

panel

When Developers Stop Opening the Editor, Chat Becomes an Interrupt Handler
When Developers Stop Opening the Editor, Chat Becomes an Interrupt Handler

The observation that organises this session is not about capability but about attention. Engineers increasingly file a ticket rather than opening an editor, and the code comes back — which changes what the surrounding tools are for. If the agent works while you do something else, the conversation between you is no longer a workspace; it is the mechanism by which the agent surfaces a question it cannot resolve alone. Interfaces built for continuous conversation optimise for flow, and interfaces built for interruption should optimise for the opposite. A runtime constraint follows immediately: an agent that starts a long-running job cannot block until it finishes, which turns out to be a workflow-engine problem rather than a model one. The panel's closing formulation — that deciding what to build is the hard skill and always was — reads as reassurance and functions as a warning, since that judgement is downstream of exactly the work now being delegated.

panel

The Moment It Stops Being Single Player
The Moment It Stops Being Single Player

The most honest moment here is an aside about how the presenters have tracked their own projects: plans in documents, plans in spreadsheets, plans in bug comments, and once a plan written on a receipt. That describes the actual category being addressed — not software nobody has built, but the small internal tool every team improvises badly because building it properly was never worth the effort. The demo turns on a single question: the generated app is strictly single player, so what happens when you want to share it with the team? That boundary is where improvised tools historically died, because it is where accounts, shared storage and access rules begin. Here it is crossed in one step, with the access rules generated and deployed automatically — which is convenient, and is also the moment the application acquires obligations nobody reviewed.

session

Pichai Calls Google a Buffer Between People and the Raw Internet
Pichai Calls Google a Buffer Between People and the Raw Internet

Pichai's framing of Google as the buffer between people and the raw internet is offered as continuity — search did it, browsers did it, agents do it more — and it is also the most contested claim in the industry, because a buffer decides what passes through. He reaches immediately for the counterweight, the connection people feel to creators they follow, which is precisely the tension the company is currently managing without resolving. Two answers are sharper than the format usually produces. On competition he describes participants running on different pre-training and release cadences rather than at different speeds in one race, which is a more honest account than the leaderboard framing and comes from someone with an interest in leaderboards. On security he acknowledges models improving at cyber work, which is the one domain where better capability does not obviously net out positive, since an attacker needs one vulnerability and a defender needs all of them.

fireside