The Five Fields Your AI Authorization Doc Is Missing

Google shipped Gemini Spark this morning. A 24/7 proactive agent. The Gemini app got a new Agent tab next to Chat. The phrase from the unveil I keep returning to: Spark “can share your info or make purchases without asking.”

I want to write about that phrase, because the debate everyone is having about it is the wrong one.

The takes I have seen since 8am Kyiv are mostly variations of “is this safe” or “is this useful.” Those are reasonable questions. They are also the wrong center of gravity for anyone whose job is to authorize this thing inside an organization.

The actual question is structural. Every AI authorization framework we have was built for tools with sessions. Trigger. Run. Stop. Review. Close. Spark has no sessions. So the doc that used to govern the agent is suddenly governing only the deployment date, and the agent runs continuously in the space the doc does not describe.

That is the whole problem. The doc shrinks. The runtime grows.

What Got Filed Before Spark

I have written or co-signed dozens of these authorization records. They have a deployment date. They have a scope definition. They have a security review summary. They have a named owner.

That structure was built for tools that have a clear start and stop boundary. A scheduled job runs at 2am, finishes by 2:30am, logs what it did, and the record describes that entire shape. The doc says “this is what this thing is allowed to do during a run.” The run ends. The authorization waits for the next run.

For Spark, there is no next run. The current run never finishes.

So the doc says “this is the scope” and Spark says “great, I will operate under that scope continuously, with no checkpoint, no idle state, no end-of-day, until someone tells me to stop.” That is not a misuse of the doc. That is the doc applied literally to a runtime it was never designed for.

The Operational Review Schedule

I have been calling the missing artifact the operational review schedule. It is one page. It sits alongside the deployment authorization. Same approver. Five fields.

Review cadence. When does the PM re-evaluate the agent? Monthly, quarterly, event-driven. Pick one. File it. The default in every framework is implicit (”at deployment”) and the default fails the moment the agent runs continuously through a team change.

Trigger events. What conditions force an unscheduled review? Vendor changes the model behind the API. Team member with elevated access leaves. Connected system changes data classification. Agent breaches an SLO. Agent encounters a class of action it has not been seen taking before. Three to five named events. Real, observable, attached to incident response.

Permission decay window. This is the field I have not seen named in any framework I have read this year. Each permission gets a half-life. Absent re-affirmation by the owner-of-record, the permission lapses. The persistent agent cannot keep an old scope alive past its decay date without an active refresh. If you have ever rotated an API key on a 90-day schedule, the shape is the same. Permission decay applies that pattern to the authorization itself, not just the credential underneath it.

Owner-of-record refresh. The team that authorized the agent is not the team running it today. The persistent agent does not move when people move. The field defines the current owner, not the name at deployment, and the cadence they re-sign. This is the human accountability field. It is the field most likely to be technically correct (someone’s name is on the doc) and operationally wrong (that someone left two quarters ago).

Sunset criteria. The deployment date answers when the agent started. Sunset criteria answers when it stops being authorized to keep running. Workflow no longer in use. Vendor product discontinued. Total cost exceeds threshold. Agent fails to renew under the decay window. Most frameworks have the first and not the second. The persistent agent does not fit that asymmetry.

Five fields. None of them are in any framework I have read on the market.

Worked Examples

Each field deserves a concrete shape so it does not read like an abstract checklist.

Review cadence in practice: quarterly is the default I would file for most teams. Monthly for any agent that touches production data outside its team’s perimeter. Event-driven only for agents whose entire job is to react to events you have already defined.

Trigger events in practice: I would not file fewer than three and not more than seven. The list is doing work only if the team can recognize the event when it happens. “Vendor changes the model” should map to a real watchlist. “Owner leaves” should map to your HR off-boarding flow.

Permission decay in practice: 90 days for read access, 30 days for write access, 7 days for any new action class the agent has not exercised before. A renewal is the owner-of-record actively re-affirming. Silence is not renewal.

Owner-of-record refresh in practice: re-signed every six months, or on the first review cadence after the named owner changes role, whichever comes first. The cadence is in the schedule, not in HR.

Sunset criteria in practice: one of the four conditions above, named at the time of authorization. The condition is not “we will figure it out when we get there.” That is not a sunset criterion. That is a deferral.

A Sidebar on Scale

Sidebar, because this is not the spine of the piece. IBM and beam.ai published a report yesterday projecting 1,600 AI agents per enterprise by year-end and noting that 88% of pilots never reach production and 70% of executives say their AI governance is not fit for purpose.

The number that matters in that report is not 1,600. It is “not fit for purpose.” That is what the persistent-agent surface does to a session-scoped framework. The framework still exists. It still applies. It just no longer covers most of what the agent is doing.

The operational review schedule is the field-level answer to the executives’ diagnosis. Five fields. One artifact.

The Career Argument

I want to close on the part of this that is not about Spark.

The PM who writes the operational review schedule owns the agent. Not because the schedule grants them authority. Because the schedule names them as the person who decides what the runtime contract looks like, who renews permissions, who calls the sunset.

Before Spark, that role existed implicitly. The PM with the deployment doc owned the agent until the agent stopped, and then the next PM owned the next deployment. With persistent agents, that handoff never happens. Someone owns the agent continuously, or no one does. The schedule is what makes “someone” identifiable.

If you are a PM whose work has felt softer since you started using AI tooling, this is the artifact I would write first. It is one page. It composes with the deployment doc you already filed. It does not require a new approval cycle. It puts your name on the runtime, not just the launch.

Spark is the first product on the market that genuinely needs this artifact attached to its authorization. It is not the last one shipping this year. The cloud agentic toolkit pricing changes are coming. The Aluminum OS announcements are coming. Every one of them will assume a runtime contract that the deployment doc alone does not describe.

You can either write the schedule for those agents, or wait for someone else to write it for you.

I would rather be the one writing.

Which of the five fields is missing from your current authorization today?