Google Cloud, AI
The CTO’s guide to governing AI agents on Gemini Enterprise Agent Platform (GEAP)
Ask a company how it governs its AI agents, and you will usually hear about a policy, an acceptable-use document that lists approved tools and prohibited data. That holds until an agent does something the policy forbids, and everyone learns the difference between writing a rule and enforcing one.
Governing AI agents on Gemini Enterprise Agent Platform (GEAP) is the chance to close that gap, because governance here is written, enforced, and measured in one place. It works across three layers, and collapsing them into one is why so many programs look governed on paper and fall apart in production.
- The policy layer is what is allowed: which agents can run, what they can touch, and how much they can do on their own.
- The enforcement layer is what actually stops a disallowed action before it happens. It is a control that sits in the request path.
- The measurement layer is how you know any of it is working: whether agents are staying inside policy, where they drift, and how fast you can trace what one did.
Most organizations have the first layer and call it done. GEAP is one of the few platforms that gives you all three, and the third, measurement, is the part almost nobody talks about. It is also the part that separates governance you can defend from governance you are quietly hoping still holds.
This is the fourth guide in a series. The definitive guide to GEAP covers what the platform is. The CTO’s guide to Shadow AI covers why ungoverned agents are a security risk. The guide to implementing GEAP covers how to stand the platform up. This piece covers what comes after: running governance as a living practice on GEAP, measuring whether it works, and building the culture and training that make governed automation something people adopt instead of route around.
Why does a one-time AI policy stop working once agents are live?
A written policy assumes the thing it governs stays still, and an AI agent changes constantly after you approve it. The model behind it gets updated, the data it reads changes as your systems change, and the tasks people hand it expand as they find new uses. An agent you documented in January is doing different work by April, against different data, on a newer model.
That is the practical reason agent governance has to run continuously. A model-era AI policy reviews outputs before release, when there is a clear artifact to check. An agent produces actions and takes them across your systems while it runs, which is what makes its risk profile different from a chatbot’s and its behavior a moving target. The controls that govern it have to watch it while it operates, because the moment they stop, the policy is describing an agent that no longer exists.
Continuous governance depends on two things being in place before you can measure anything: a person accountable for each agent, and enforced limits on what each agent can do. The next two sections set those up, and the one after shows how you measure them.
Who owns an agent on GEAP, and what breaks when no one does?
Governance needs an owner before it needs a policy. Most companies set up the familiar structure here: an executive accountable for AI risk, usually the CIO or COO, and a cross-functional group from security, legal, and the business that reviews what gets deployed. That structure is table stakes, and it is the same one any AI program needs.
The agent-specific requirement is a named human owner for each agent. An agent takes actions under some authorization, so a person has to answer for what it does, the way a manager answers for a report. An agent with no owner runs on whatever permissions it inherited at setup, which are rarely scoped correctly, and no one reviews what it touches until it touches something it should not. That is how Shadow AI returns inside a Google-branded platform, where it looks governed while behaving exactly like the exposure you were trying to close.
Three things need a named owner from the start:
- The agent inventory, so one person is accountable that every running agent is registered and attributed
- The autonomy policy, so one person decides and signs off on how much each agent can do on its own
- Incident response, so when an agent takes a wrong action, one person coordinates the fix instead of a committee forming after the fact
GEAP makes ownership enforceable, because you can only assign an owner to an agent you can see.
Agent Registry keeps a live inventory of every agent running in the organization. Agent Identity gives each one a unique cryptographic ID, so every action traces to a specific agent and the authorization behind it.

Source: Codelabs
How to set agent permissions with autonomy tiers?
An acceptable-use policy for agents comes down to one question: how much is each agent allowed to do on its own? The clearest way to answer it is to define tiers of autonomy and move an agent up only when its logged behavior earns the promotion.
The three tiers below are the policy. What turns them into governance is the last column. Each tier maps to a GEAP control that enforces it in the request path, so the limit is a check an action has to pass rather than a line someone is trusted to follow.
|
Autonomy tier |
What the agent may do |
Human oversight |
Promotion gate |
GEAP control that enforces it |
|
Assisted |
Draft and recommend; a human approves every action |
Human in the loop, on every action |
Accurate recommendations logged across a set window |
Agent Gateway connection controls, paired with an ADK-built human-in-the-loop approval workflow |
|
Supervised |
Act on low-risk actions alone; high-risk actions still need approval |
Human on the loop, reviewing the decision chain afterward |
Low error rate and zero scope violations across the window |
Gateway policy, Model Armor, Agent Observability traces |
|
Autonomous |
Act without per-action review inside a bounded scope |
Exception-based escalation only |
Sustained in-policy behavior and a tested rollback path |
Gateway scope limits, Agent Identity least-privilege, Model Armor |
Two rules keep the tiers honest. Promotion is evidence-based, so an agent advances only when its logged behavior across a defined window earns it, which is why the measurement in the next section is what makes higher autonomy safe. And the audit trail has to record the full decision chain, from the prompt to the plan to the tool calls to the final action, because reconstructing why an agent acted is what an incident review actually needs.

How is AI governance measured on GEAP?
Enforcement stops one bad action. Measurement tells you whether your governance is holding across every agent, where it is slipping, and how fast you can answer for what an agent did. On GEAP, the controls produce that measurement as a byproduct of running, so a governance owner has a specific set of signals to track.
- Inventory coverage: the share of running agents registered and attributed to an owner, from Agent Registry. Anything unregistered is Shadow AI under another name.
- Attribution: whether every action traces to one agent identity and the authorization that permitted it, from Agent Identity, which turns an audit into a query rather than an investigation.
- Blocked actions: what Agent Gateway stopped, including attempts outside an agent’s scope and connections denied. A rising count on one agent is an early signal it is misconfigured or misbehaving.
- Threats intercepted: prompt-injection and data-leakage attempts caught by Model Armor before they reached a model or a system.
- Behavior drift: whether an agent still performs the way it did when you promoted it. Agent Evaluation scores agents against live production traffic, so drift shows as a falling score before it shows as a complaint.
- Time to trace: how fast you can reconstruct why an agent took an action. Agent Observability gives full execution traces, which turns incident response into a number you can manage down.
Tracked together, these are a governance dashboard. They also feed the autonomy tiers directly: an agent earns promotion when its blocked-action count, drift score, and scope adherence stay clean across the review window, and it gets demoted the moment they do not.
How do you get employees to use the governed agents?
Every control in this guide fails the moment employees work around it, and they work around it when the governed path is slower than the alternative. This is the same dynamic behind Shadow AI: people reach for a personal AI account because it is faster than the sanctioned tool. The job is to make the agent running inside GEAP the faster, better option, so the governed path wins on merit.
Training is the first lever, and it works best in three tiers:
- Awareness for everyone, so people know what an agent is and what it can and cannot be trusted to do.
- Applied skills for daily users, so the people handing work to agents can do it well.
- Advanced training for builders, so the engineers writing agents understand scoping, evaluation, and failure modes.
The skill that generic AI training skips is judgment: knowing when an agent’s action can be trusted, how to read its decision chain, and when to escalate instead of approve. That judgment is what lets you raise autonomy tiers without raising risk.
Culture is the second lever, and it outperforms mandates. Adoption spreads faster through champions, the pilot users who already work through agents daily and carry credibility a policy email never will, than through a top-down directive. Measure adoption by whether people complete real work through governed agents, and put the effort into making those agents good enough that the shadow alternative stops being worth the risk. Revolgy’s AI adoption program pairs the technical rollout with this training and change-management work.
Govern your AI agents with Revolgy Experts
GEAP is a comprehensive platform, and that comprehensiveness is what makes governing it well a real skill. Getting the ownership model, the autonomy tiers, the enforcement controls, and the measurement layer working together takes experience most engineering teams are building from scratch on their first deployment.
Revolgy is a Google Cloud Premier Partner that has deployed and governed GEAP across industries and organizations at different stages of AI maturity. The engagement follows three phases, each building on the last so governance is in place before scale, and scale happens before optimization:
- Phase 1, Foundation and quick wins: discovery workshops map your highest-value use cases, baseline governance including Agent Identity, Gateway, and Model Armor is configured from day one, and quick-win agents prove value before you scale.
- Phase 2, Custom agent development: purpose-specific agents are built with ADK, scoped to your permissions and connected securely to your existing tools including Jira, Salesforce, and other systems.
- Phase 3, Adoption & optimization: team training and change management roll out, automation expands across the organization, and governance and cost controls are tuned as usage grows.
Book a free 45-minute Architecture Clinic with a senior Revolgy Google Cloud architect to talk through your governance model. Bring a real active GEAP or agent problem, and you leave with a structured summary of the gaps and your next steps within 24 hours. Only 6 slots run per week. Claim yours now!
Frequently asked questions
What does it mean to govern AI agents on GEAP?
Governing AI agents on GEAP means running three parts together: deciding what an agent may do, enforcing that decision on every action it takes, and measuring whether the enforcement holds across every agent. GEAP provides the controls for all three, including Agent Gateway for enforcement, Agent Registry and Agent Identity for ownership and attribution, and Agent Evaluation and Observability for measurement. Writing an acceptable-use policy covers only the first part.
How is governing an AI agent different from governing an AI model?
Governing an AI model means reviewing its outputs for accuracy, bias, and compliance before release. Governing an AI agent means controlling its actions, because an agent takes steps across your systems while it runs. That changes what you govern to identity, authorization, autonomy limits, and an audit trail of what the agent did, rather than a single output you can check.
How do you measure whether AI agent governance is working?
You measure it through the signals the controls produce: how many agents are registered and owned, how many actions the gateway blocked, how many threats were intercepted, whether agent behavior is drifting, and how fast you can trace an incident. On GEAP these come from Agent Registry, Agent Gateway, Model Armor, Agent Evaluation, and Agent Observability. Read together they form a governance dashboard rather than a set of disconnected logs.
Who should own an AI agent?
Each agent needs a named human owner accountable for what it does, sitting under an executive owner for AI risk, usually the CIO or COO, and a cross-functional review group. The per-agent owner matters most, because an agent with no owner runs on inherited permissions that no one reviews. GEAP’s Agent Registry and Agent Identity are what make that ownership assignable and auditable.
What are autonomy tiers for AI agents?
Autonomy tiers define how much an agent can do on its own, from assisted, where a human approves every action, to supervised, where it acts on low-risk actions and a human reviews afterward, to autonomous, where it acts within a bounded scope with exception-based escalation. An agent moves up a tier only when its logged behavior earns it. On GEAP each tier maps to a control, so the limit is enforced at runtime.
How do you stop employees from using shadow AI tools instead of governed agents?
Make the governed agent faster and better than the shadow alternative, because people route around sanctioned tools mainly when those tools are slower than a personal AI account. Drive adoption through champion networks and role-specific training rather than mandates, and measure real workflow usage instead of logins. When the governed agent is the best tool available, adoption and governance stop competing.