Google's announcement on October 8, 2026 gives agents a long list of enterprise controls: their own identity, permissions, sandboxing, network rules, audit logs and spending limits. Every one of those is a real improvement, and none of them answers the question a business actually has to answer before it lets an agent work.
That question is which actions a person must approve. No control panel ships with that filled in.
The Gemini at Work 2026 post describes an agent that runs in the cloud and keeps one set of memories, context and personalisation across devices, so you never have to brief it again. It can live inside Workspace, Microsoft 365 or Slack, and it can run as a headless agent with no interface of its own.
On governance, the post lists "identity and policy management, authorization and permission controls, secure sandboxing, network gateways, and more". On cost, it describes "multi-model orchestration, Smart Routing, real-time spend caps" and links to a separate piece on flexible billing and cost controls for agents.
Those are the right primitives. The distinction that matters is that they are primitives, not policy.
Read the middle column again. Each control reduces a class of damage. Not one of them notices that refunding a customer 400 times in an afternoon is legitimate use of a correctly configured permission.
OpenAI's confirmation and consent guidance for agents that operate software says it in operational language: keep a human in the loop for purchases, authenticated flows, destructive actions, or anything hard to reverse. It also warns that content on a page cannot grant permission, because the agent reading a document is not the same as the owner authorising an action.
Turn that into a business rule and it looks like a short list: actions the agent may take alone, actions that stop for a named person, and actions it may never take. Everything else follows from it, including the permission scope you grant and the alerts you configure. The same pattern is covered for a browser agent in a site approval is not an action approval and in bounded permissions and human approval.
Spend caps belong on that list too, and they are a business decision rather than an engineering default. Capping the agent at a level that blocks routine work creates a queue of stalled tasks nobody owns; capping it so high that it never triggers makes the cap theatre. Pick the number against what a wrong action costs, not against what the invoice last month looked like.
Write these down once, because they are the questions that will otherwise be answered by whoever is closest when something goes wrong.
An agent that reads public information and drafts a summary does not need identity management, sandboxing or spend caps, and configuring them wastes the setup time you could spend on the writing. The controls start to earn their place when the agent holds a session, reaches authenticated screens, or touches money, records or customers. That line is worth drawing explicitly, because the alternative is buying governance for a tool that only needed a proofread.
No. They limit the damage an agent can do inside the boundary you draw. They do not decide where the boundary belongs, which is a business decision about which actions are reversible and which are not.
Actions. A spend cap limits what a mistake costs. An approval rule stops the mistake happening. Apply the approval rule to anything hard to reverse, then cap the spending on the tasks that run unattended.
The person accountable for the process the agent runs, not the person who configured it. Configuring is a one-time task. Owning the rules means updating them when the process changes, which is the part that decays.
It is necessary and not sufficient. A log proves what happened after the fact. What auditors and customers tend to ask is who approved the action and under what rule, which means the approval step has to exist before the log can show it.
Maxpertise builds and runs the AI team that operates your business, in a managed lane where we host and run the team, or an embedded lane where AI engineers work inside your existing team. Both lanes run on the same two human gates: a person approves the plan before anything is built, and a person reviews the result before it ships.
The rule layer described above is not paperwork we add at the end. It is the deliverable that makes the controls mean something, which is why the work starts from a written spec you can read, as described in spec-driven development with AI agents. Roles that touch money and customers, like the AI back office, get their approval rules in the same document as their permissions.
The adoption research is clear that most small businesses are still experimenting in isolation rather than running on AI, which is the gap covered in 66% use AI, 9% embed it. Deciding which actions need a person is the step that moves a business across it. If that is where you are, the method is at how it works, the engagement options are on pricing, and a written intake at contact with your three lists is enough to scope it.
[1] Google Cloud, Welcome to Gemini at Work 2026: Introducing the Gemini agent, October 8, 2026. Persistent execution, headless operation, the governance controls, the cost controls, and the named small and midsize business users.
[2] Google Cloud, Flexible billing and cost controls for agents on Google Cloud, accessed October 10, 2026.
[3] Google Cloud, Gemini Enterprise, accessed October 10, 2026.
[4] OpenAI, Computer use integration: handle user confirmation and consent, accessed October 10, 2026. Human in the loop for purchases, authenticated flows and destructive actions; untrusted content cannot grant permission.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.