The Agent Keeps Working After You Log Off: Gemini Spark, Always On Cloud Agents, and the Supervision Control That Quietly Stopped Working

Google has begun rolling out Gemini Spark, an always on personal agent, to subscribers in the United States on the AI Ultra tier at roughly 100 dollars a month, with access reported at the AI Pro tier at about 20 dollars a month under tighter usage limits. The technical detail that matters is not the model behind it. It is where the work happens. Spark tasks run on dedicated virtual machines in Google Cloud rather than on the device in your hand, which means the agent keeps executing when the laptop lid closes and when the phone locks. It connects natively to Gmail, Docs, Sheets, Slides, Drive and Calendar, reaches third party services including Canva, OpenTable and Instacart through Model Context Protocol connectors, and can be handed work by forwarding a thread to a dedicated address. Google states that permissions are off by default, that the user chooses which applications to connect, and that the agent is designed to ask first before high stakes actions such as spending money or sending mail. Read that list again as a control description rather than as a feature list, because every item on it is an access decision that somebody in your organisation is about to make on a personal subscription.

The load bearing change is temporal, and it is worth being precise about why. For the past two years the standard answer to agent risk has been human oversight. Keep a person in the loop. Require confirmation before consequential steps. Review the output before it goes anywhere. Those controls are written into AI policies, into vendor questionnaires, into board papers, and into the clause level answers organisations give assessors about how they supervise automated processing. Every one of them carries a silent assumption: that the human and the agent are present at the same time, because the agent only runs while somebody is looking at it. A session bound assistant enforces that assumption for free. An agent that runs on a cloud virtual machine while the person who started it is asleep removes it entirely, and nothing in the policy language tells you that it has been removed. The control still reads correctly on the page. It has simply stopped describing the system.

The second change is who holds the contract. This is a consumer subscription, bought on a personal card or an expense claim, and the coverage so far does not document Workspace administrator controls or approval checkpoint configuration for shared and enterprise accounts. Compare that to how the same capability arrives through a normal enterprise channel, where a Workspace or Microsoft tenant administrator can enable a feature, scope it to an organisational unit, log it and turn it off. Here the enabling decision sits with an individual, and the artefact that grants access is an OAuth authorisation between the person who is signed in and the agent platform. If the person is signed in to a corporate Google account when they connect Gmail and Drive, the agent now has standing, persistent, unattended access to corporate mail and corporate documents under a contract your organisation never signed. This is different in kind from the browser agents we covered earlier this year, which inherit whatever session is already open in front of a human. Spark is not borrowing a session for the length of a task. It is holding a durable grant that outlives the session, the device and the working day.

That distinction determines where the real control point sits, and most teams will look in the wrong place first. The instinct is to reach for device management, network controls or an application allowlist, none of which help when the execution is happening on a virtual machine in a Google region rather than on the endpoint you manage. The asset that matters is the authorisation grant, and the places you can see it are the account level connected applications list and, where the account is part of a managed tenant, the administrative view of third party application access and API scopes. That is also where offboarding breaks. Suspending an account and revoking a session are not the same action as revoking a token, and an organisation that treats mailbox disablement as the end of the offboarding checklist should ask a direct question about queued and recurring tasks: if a departing employee left a standing instruction that runs every morning, what stops it, when, and who can prove that it stopped. If the answer is that nobody has checked, that is not an exotic AI risk. It is an access review finding waiting to be written by somebody external.

There is a supply chain layer on top of this that follows directly from the connector model. Every MCP connection the user approves adds a third party that receives content from your corporate systems, chosen at the moment of use, by a person who is not in your procurement process, under terms that person accepted on their own behalf. We have argued before that MCP servers are vendors and belong in the third party register, and the always on case sharpens the point rather than changing it, because the data flow no longer requires the person to be present to trigger it. A design brief that goes to a design service, a booking that carries a client name, a spreadsheet summarised through a connector at three in the morning: each is an ordinary transfer that a register built around signed contracts and annual reviews will simply never see. Your register is not wrong. It is asking a question, which vendors did we contract with, that no longer captures the population, which is which services actually received data.

The framework mapping is unglamorous and almost entirely conventional, which is the useful part. ISO 27001 expects an inventory of assets and information, access provisioned and reviewed against documented authorisation, and supplier relationships managed, and a standing grant to corporate mail issued by an individual to a service you have not assessed fails all three at once. The SOC 2 common criteria expect logical access to be authorised, reviewed and removed on a defined basis, and expect you to monitor what is running against your systems, so an unattended process acting with staff privileges belongs in your access review population and in your logging scope. ISO 42001 is the sharpest of the three here, because it asks for an inventory of AI systems with a recorded purpose and a named owner and it asks for human oversight to be defined and effective, and an agent nobody has listed, operating while nobody is watching, misses both requirements at once. For Australian organisations the Privacy Act obligations on disclosure and on taking reasonable steps to protect personal information follow the data rather than the subscription tier. Be precise about the platforms: Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof will confirm your access review ran and your AI policy is approved, and they will not tell you that a marketing manager connected a personal agent to a corporate mailbox on Tuesday. Our compliance readiness tool, our ISO 42001 material and the access control and supplier templates in our policy templates library all assume a human maintains the list of identities and third parties, and that assumption is exactly what an individually purchased agent bypasses.

The fair counterargument deserves stating properly, because the design here is better than the average. Permissions off by default is the correct default and many products get it wrong. Asking before high stakes actions is a real control rather than a marketing line. A staged rollout limited to one country and to paying tiers is a responsible way to discover blast radius, and Google publishing guidance to supervise closely and to manage standing access carefully is the vendor telling you plainly where the risk sits. None of that is the problem. The problem is the familiar mismatch in rates: capability arrives through consumer channels in weeks, and governance arrives through enterprise channels in quarters, and in the gap between them the deployment decision is made by an individual optimising for getting the work done. That is not a criticism of the individual either. Somebody handed a tool that clears their inbox overnight will use it, and telling them not to without offering a sanctioned path produces concealment rather than compliance.

The exercise for this week takes an afternoon and leaves you with something durable. First, answer the question factually rather than by policy: pull the connected applications and third party access report for your Google or Microsoft tenant, filter for agent and assistant platforms, and count how many staff accounts have already granted mail or file scopes to something your organisation did not procure. Second, decide and publish a position in one page before the question reaches you informally, covering whether corporate accounts may be connected to personally purchased agents at all, which data classes are never in scope, and who approves an exception, because a written position that says not yet is far better than silence. Third, fix the offboarding gap concretely by adding token and grant revocation as a named step with an owner, and test it once against a real leaver rather than assuming account suspension covers it. Fourth, add unattended automated processing to your access review population, so that an identity acting outside working hours is reviewed like any other privileged access instead of falling between the human and service account categories. Fifth, extend your third party register to record runtime discovered connectors with the data class involved and the internal owner, since a register that only counts signed contracts will keep reporting zero while data moves. Sixth, put the sanctioned alternative in front of staff at the same time you publish the restriction, because the demand behind this is genuine and unmet demand routes around governance. The last two years of AI oversight rested on a quiet assumption that somebody would be watching when the action happened. It is worth checking whether that is still true of anything you run.