Google's Gemini agent asks four governance questions. Your approver needs a fifth.
Google's new Gemini agent can act on your systems, and nothing in Google's launch post makes a permitted action wait for a person first. That is not a flaw in the product. It is the gap Google left for you to fill. It is narrow, and you can close it before anyone turns the agent on.
On Thursday Google Cloud announced the Gemini agent. In Thomas Kurian's words, you give it "objectives, not instructions"1. It plans the work and connects to your systems: Workspace, Microsoft 365, Slack, Jira, Salesforce, ServiceNow, Snowflake. It also reaches "any Model Context Protocol (MCP) server inside or outside your company network"1. It can spin up sub-agents, "each with their own identity." Coworker agents get their own @agents.company.com email address, calendar and Drive1. Google says nearly 90% of the Fortune 100 already use Gemini Enterprise1. And businesses get the agent before consumers do2.
Google's four questions
Google's post is serious about control. It says governance "comes down to answering four fundamental questions"1:
- /01
Who is the agent, and what identity does it have?
- /02
What is it allowed to do or what permissions is it granted?
- /03
What did it do and where can I see what it did?
- /04
What should it never touch?
Each gets a real answer. Every agent has an identity "governed like an employee, with least-privilege permissions." Permissions are "approved by your organization's security administrators." Every action is "written to an audit trail and attributed to the agent rather than to a person." All traffic passes through Agent Gateway, which enforces a policy you write once. Google's example: "agents may not open documents classified Need to Know"1.
That beats most teams' defaults. Take it.
The question that is not on the list
Read the four again. They cover who the agent is, its standing access, its history and its hard limits. None of them covers the moment that matters to your controller. The agent is allowed to do something, and is about to do it to a large amount of money.
Picture it. Say your AP agent has write access to the vendor master. It must, or it cannot do its job. On Tuesday it decides to change a supplier's bank details because an email asked it to. Identity: fine, it is the AP agent. Permission: fine, it can edit vendors. Never-touch list: vendors are not on it. Audit trail: the change will be recorded, attributed to the agent, after it happens.
Every one of Google's four answers is yes. The payment still goes to the wrong account.
TechCrunch reports the agent "knows ... who needs to approve items"2. Knowing who approves is not the same as waiting for them. A permission is set once, by a security admin, for a whole class of action. An approval is given per action, by the person who owns the outcome. Google's list covers the first. The fifth question is yours:
Which actions does the agent have to stop on, and who signs before it continues?
The spend cap is a hint
Google does offer one hold. Real-time spend caps pause a project's agent when its AI spend hits a limit, and someone resumes it "with a single click in the console"1. That is the right shape. It stops before the next step, someone decides, and the work picks up again.
But it watches what the agent costs you in tokens. It does not watch what the agent does with your money. A cheap run can still send a large wire. Point the same pattern at the action.
What to do before you switch it on
1. List the actions, not the apps. "Can use NetSuite" is a permission. "Can change a vendor's bank account" is an action. Write ten of those for one process.
2. Mark which ones hold. Bank detail changes, payments over your threshold, new vendors, refunds, anything sent outside the company. If you would want a second person to look at it when a human does it, the agent holds too.
3. Name one approver per hold. A person or a role, not "finance". Make sure it is not whoever assigned the objective. An agent acting on your behalf should not get its sign-off from you. Segregation of duties covers why.
4. Watch the sub-agents. Google's sub-agents are "temporary, job-specific agents, each with their own identity"1. Ask your admin whether a hold set on the parent applies to every sub-agent it spawns. Test it. Do not assume.
5. Prove a hold waits. Give the agent an objective that needs one held action. Confirm it stops and nothing changes until the named person says yes. Then check the audit trail shows who approved.
What changes
Google gave its agent an email address and a badge. That settles who the agent is. It does not settle who answers for what it does next.
That is the layer a control plane sits in. In Gatehouse, the rules say which actions hold. Each one waits for one named approver, and the decision lands in the record next to the action. It works alongside the identity Google now provides, not instead of it.
Start with step 1 this week. What is an agent approval policy? walks through one. Want a second pair of eyes on it? Book a teardown.
Sources
Want the next one? News with a take, three times a week. Follow by RSS
Read next
What is an agent approval policy?
An approval policy decides which agent actions go ahead, which wait for a person, and which never happen. Most teams have a paragraph. You need a table.
How a hold works: triggers, named approvers, cover and time limits
Human in the loop only works if each hold has four parts: a trigger, one named approver, a named cover, and a time limit. What each part does, and what happens when one is missing.
Segregation of duties for AI agents: when one agent initiates and approves
Segregation of duties says no one person should initiate, approve and record the same transaction. An agent that does all three breaks the rule. How to map SoD onto agents.
