Governing Gemini Enterprise Agents: Access, Model Armor and the Audit Trail

Most teams approach agent governance the way they approach a security questionnaire: work down the list of available controls and turn them on. Model Armor gets enabled, logging gets switched to verbose, an approval step gets added somewhere near the end, and the box is ticked.

The result tends to be a system that is simultaneously over-restricted and under-governed. It blocks a lot of harmless requests, which trains users to route around it, while leaving the actual exposure untouched because nobody established what the agent could reach in the first place.

There is an order that works better, and it runs from the inside out: reach, then action, then content, then record.

Everything else is decoration if this is wrong. An agent that can retrieve a document it should not have seen has already caused the incident, whatever happens to the text afterwards.

Gemini Enterprise scopes retrieval to the requesting person's existing entitlements, which is the correct model. Your job is to make sure those entitlements are actually right in the connected systems, and to be able to show the working. We ask one question per connected source: if this agent surfaced everything in here to the wrong person, what is the worst single document that comes out? If nobody can answer, the source is not ready.

The useful discipline is that reach is a property of your identity and permissions estate, not of the AI platform. Fixing it improves your security posture whether or not the agent ships.

The gap between an agent that drafts and an agent that sends is the largest single risk decision in the whole deployment, and it is often made implicitly by whoever wired up the integration.

We classify every action an agent can take by whether it is reversible and whether it is visible outside the organisation. Reversible and internal, such as updating a ticket field, is a reasonable place to let an agent act unattended. Irreversible or externally visible, such as sending to a customer, issuing a credit or changing an entitlement, holds a human in the loop until the evaluation history justifies otherwise.

This is not permanent caution. It is a ratchet you earn your way along with evidence, and being explicit about where you currently sit on it is what lets a risk function say yes.

This is where Model Armor sits, and where the two threats worth caring about are prompt injection and data leakage.

Prompt injection is the more interesting one once agents can act. If an agent reads a document, and that document contains instructions, you now have a system that takes direction from anyone who can write into your connected sources. That includes a supplier who can attach a PDF to a ticket. The mitigation is partly filtering and substantially the previous section: an agent that cannot take an irreversible action unattended is a much less rewarding target.

Leakage runs the other way, and the practical control is deciding in advance which classes of content should never leave a boundary regardless of who asks, then testing that with the specific phrasings your own people would naturally use rather than with adversarial red-team prompts alone.

The audit question is never asked while things are going well. It is asked once, urgently, about something that happened eleven weeks ago.

What satisfies it is not a usage dashboard. It is the ability to reconstruct a specific interaction: who asked, what was retrieved and under whose entitlements, what the agent did, what came back, and whether a human approved anything along the way. Gemini Enterprise gives you the central place to see and audit agents; what varies is whether your deployment recorded enough to answer the question people will actually ask.

Our test is simple and worth running before go-live. Pick a real interaction from last week. Ask someone who was not involved to reconstruct it from the record alone. If they cannot, you do not yet have an audit trail. You have logs.

The failure mode that creeps up slowest is proliferation. Every team builds the agent that solves their problem, each one is individually sensible, and eighteen months later nobody can answer how many agents exist, what they can reach or who owns the ones whose author has left.

The central governance framework exists precisely to prevent this, but only if registration is the path of least resistance rather than a review board that takes three weeks. In practice the useful rule is that an agent may be built quickly by anyone, and may only reach production data through the registered route. Make the governed path the fast path and the shadow estate does not accumulate.