Your AI Agent's Permissions Did Not Change. Its Authority Still Did.

Google announced Gemini 3.7 Flash on 13 August 2026. Buried in a post that is mostly about coding benchmarks and a halved introductory price is one sentence that matters more than the scores: Gemini Spark, Google's personal agent, started using the new model the same day.

Nobody edited a permission. Nobody granted Spark a new application. The agent that ran your scheduled tasks on Wednesday and the agent that runs them on Friday have the same access to the same accounts. The model underneath them is different.

What Google actually said

The announcement is precise, so it is worth using Google's own words rather than a bigger paraphrase.

Google describes 3.7 Flash as its most intelligent workhorse model yet for coding and agents, arriving three weeks after 3.6 Flash. On execution behaviour, Google writes that the model better adapts to roadblocks, clarifies intent when needed, and follows instructions with greater fidelity. It says the model thinks more diligently, putting more effort into multi step planning and tool calls, and that a more disciplined execution means less manual oversight and fewer retries across engineering workflows. Introductory pricing is $0.75 per million input tokens and $3.75 per million output tokens through 31 December 2026.

On the agent itself, Google says Gemini Spark, available to Google AI Pro and Ultra subscribers in over 160 countries, will be using Gemini 3.7 Flash starting today, and describes Spark as the personal AI agent launched at I/O that runs 24/7, taking action on your behalf while under your direction. Google says the model update makes Spark more efficient for knowledge work with improved tool use for Google Workspace apps, and improved accuracy and output quality for complex, multi skill workflows. The examples Google gives are consolidating files, drafting emails and updating status documents.

The DeepMind model card, published the same day, is consistent with this. It lists Gemini App Spark as a distribution channel, records gains on agentic benchmarks including Terminal Bench 3.0 at 14.9 percent against 5.4 percent for 3.6 Flash and OSWorld 2.0 agentic computer use at 47.9 percent against 33.8 percent, and notes updated Frontier Safety safeguards in the CBRN and cyber offense domains. I am not going to make this article about the benchmark table. The relevant fact is narrower: Google's own measurements say the agentic execution capability moved, and the agent product moved with it.

Spark already has somewhere to act

A capability improvement only matters if the system has real reach. Spark does, and Google documents it plainly.

According to Spark's help documentation, Spark can use Connected Apps and Google services including Google Workspace, which Google lists as Calendar, Docs, Drive, Gmail, Keep, Sheets, Slides and Tasks, along with Google Search services, YouTube, custom connected apps, and third party apps that Google names as Canva, Dropbox, Instacart, OpenTable and Zillow. It can use skills, which Google describes as reusable instructions with additional context, and schedules, which Google describes as automated triggers that tell Spark when to execute your instructions, either at a set time or in response to an event.

It can also browse. Google documents a remote browser and a remote computer with code execution, and auto browse through your own Chrome on desktop. On the local browser, Google states that Spark has access to all the same sites that you do, including sites you are signed into, and that with your permission it can use login information saved in Password Manager to sign into loyalty programs and online accounts. If you close your device before a task is finished, Google says Spark might use a remote browser to complete it, and that a remote browser task can continue even after you close your device.

Google is also direct about the consequence of scheduling. Its guidance says that if a schedule runs when you are offline, you may not be able to stop Gemini from completing an unintended action. That is Google's sentence, not mine, and I would rather quote it than dramatise it. Spark can also run up to 15 tasks at once.

The permission list can stay the same while the risk changes

Here is the part I actually want to argue.

We talk about agent permissions as though they describe authority. They do not. They describe reach. A permission says which door is unlocked. It says nothing about how far the thing walking through it can get.

An agent that plans two steps ahead, fumbles a tool call, hits a roadblock and stops has a small effective authority even with broad access, because it does not get far before a human notices or the task dies. Give the same access to a model that plans further, calls tools more accurately, recovers from obstacles and needs fewer retries, and the same door now leads somewhere. Google's framing of the improvement is that it means less manual oversight and fewer retries. Read that as a governance sentence rather than a productivity one: fewer interruptions means fewer moments where a human incidentally sees what is happening.

None of this means more capable is more dangerous. Most of the time it is the opposite. A model that follows intent with greater fidelity and abandons fewer tasks halfway is a model that produces fewer half finished messes in your Drive. Better recovery from roadblocks is a real safety property in its own right. The honest version of the claim is about consequence, not danger: after the upgrade, the same delegated access produces longer, more complete, less interrupted chains of real world action. Good outcomes get bigger. So do bad ones.

Google has not removed the approval layer

It would be easy and wrong to write this as a story about safeguards disappearing. They did not.

Google's documentation describes a specific set of controls. Spark is designed to ask for your review and confirmation before it completes certain actions, and Google's examples are sending communications, modifying your data, making purchases and submitting web forms. There is a take control mode where Gemini pauses and asks you to complete specific actions yourself, including entering passwords or payment details. Google says Spark shows you what it plans to do, its progress, and the skills, connected apps and files it used or created. It documents prohibited task recognition for requests that fall outside intended use, and site and action restrictions that keep browsing to sites and actions relevant to the task. Chrome asks for permission the first time Spark connects to your browser on a device, and Google says Spark asks for confirmation for every task involving web browsing. You can stop a response, take over the browser, pause a schedule or turn Spark off entirely.

Google also does not oversell any of this. Its own text says these features do not guarantee protection against all risks, that Gemini can make mistakes and do unexpected things, that your active supervision is the most important protection, and that the safeguards are not intended to replace it. It devotes a section to prompt injection, including the scenario where a page or email carries hidden instructions that cause the agent to exfiltrate data from your connected apps. Spark is labelled experimental and in early development, is limited to personal accounts for users 18 and over with a Pro or Ultra subscription, and Google lists exclusions including the European Economic Area, Nigeria, Switzerland and the United Kingdom.

So the approval layer is intact. That is exactly why the question is interesting. The controls are the same, the reach is the same, and the thing being controlled got materially better at operating.

Model upgrades are governance events too

Every organisation I know of has some process, formal or informal, for permission changes. Somebody asks before a service account gets write access to production. Somebody reviews the scopes on an OAuth grant. Those reviews exist because a permission change is understood to change what can happen.

I have not seen the same reflex applied to a model swap. The model underneath an agent changes and it is treated as a vendor improvement, which it is, rather than as a change to the amount of authority that is currently delegated, which it also is. In Spark's case the swap happened on Google's schedule, on the day of the announcement, for subscribers across more than 160 countries. There was no permission review to attend.

This connects to something I wrote about the day Claude Code made auto mode the default: the layer where human judgment applies keeps moving upward. First we approved individual actions. Then we approved plans. Then we configured trust and let a classifier apply it. A silent model upgrade is the next step up again, because it changes the behaviour that all of those configured decisions were calibrated against.

It also rhymes with the robotics case I looked at recently, where an agent worked out a step nobody had specified for it and still paused for a human before acting. Capability expanded. Authority did not, because the boundary was drawn around actions rather than around cleverness. That is the design property worth wanting here.

And the failure shape is already documented. In the Australian gym booking case, an assistant completed exactly the task it was asked to complete and took a path nobody had considered. A more capable agent does not remove that class of outcome. It finds more paths.

The question I would ask

None of this is a criticism of Google's release. Cheaper, more reliable agent execution is genuinely useful, and Google's documentation of Spark's risks is more candid than most.

What interests me is the review gap. Your permissions inventory says the same thing this week as last week. Your agent does not do the same thing with it.

When the model underneath an agent changes, who reassesses whether yesterday's permissions still represent the amount of authority you intended to delegate?