Gemini Enterprise DLP: An Admin Toggle Governs Availability, Not What Leaves in the Prompt
Google Workspace admin controls decide which organizational units get Gemini features and which apps it can ground against. Those toggles govern availability. Once a user has the feature, the content of every grounded request is decided by whatever that user has access to, which for most employees is a larger surface than anyone has audited. This piece separates the Workspace side from the Vertex API side, explains why grounding scope is the real control, and sets out where classification and per-decision records belong.
A Workspace admin enables Gemini for the whole organization, checks that data is processed inside the Workspace boundary under the existing terms, and closes the ticket. That is a correct reading of the controls available in the admin console.
Two weeks later an analyst asks the side panel to summarize everything they can find about a departing executive. The answer draws on a shared drive folder, three email threads and a calendar history, and it is accurate.
The toggle governed whether the feature exists. The content of that answer was governed by a permission model built over eleven years by people who were solving different problems.
Two surfaces with different properties
The Workspace surface covers Gemini in Gmail, Docs, Drive, Sheets, Meet and the standalone app, grounded against Workspace content the user can access. Google's enterprise terms place this processing inside the customer's Workspace boundary, with commitments about training use. Those commitments are real and they answer the vendor-retention question.
The Vertex AI surface covers applications your teams build against Gemini model endpoints. Here the data path is one your engineers designed, the destination is a Google Cloud project, and the content is whatever the application assembled. Admin console toggles have nothing to do with it.
Plenty of organizations run both, governed by two different teams, inventoried in two different places, and discussed as one product because they share a brand name. Getting a straight answer to "where does our Gemini data go" usually requires talking to four people.
Grounding scope is the control that matters
The interesting property of the Workspace surface is that it grounds on what the user can already reach.
That sounds like a safe default, and it is a faithful one. It also means the assistant's effective knowledge for a given employee equals every file, message and event that employee has access to, retrievable through a question rather than through folder-by-folder browsing.
An employee with access to 60,000 files was never going to read them. They were going to open the eleven they knew about. Retrieval collapses that distinction, and the gap between theoretical access and practical access closes overnight.
The specific findings that surface first are consistent across deployments: shared drives with organization-wide access containing HR or compensation material, legacy folders inherited from a team that reorganized, and email threads forwarded to a wide list years ago. None of this is new exposure. It is old exposure that just became queryable.
Running an access review before broad enablement costs a quarter and prevents the incident. Running it afterwards means doing the same work with an open ticket.
Where the admin controls stop
Workspace admin settings govern which organizational units get which Gemini features, and which connected apps and data sources are available. Those are availability decisions applied per user group.
Three things sit outside them.
Content classification within an allowed source is the first. A shared drive that is an approved grounding source contains a mix of classes, and the toggle authorizes the drive rather than the classes inside it.
The user's own composition is the second. An employee pasting a customer contract into a Gemini prompt in Docs is sending content the admin console never evaluated, and this is the same behaviour that produces shadow AI findings on every other platform.
The Vertex-side application path is the third, and it is governed by whatever your engineers built.
What Gemini Enterprise DLP has to classify
Classification runs on the assembled request, because grounding means the request contains far more than the user typed. The practice is prompt-level DLP, and the class definitions come from AI data classification.
For the Workspace surface, the policy question is which classes may enter a grounded prompt for which roles. Compensation data reaching an HR business partner's prompt is expected. The same data reaching a contractor's prompt, because a folder grant was never cleaned up, is the finding.
For the Vertex surface, the question is the standard one for any provider API: what class of content leaves the application boundary, under which identity, to which project and region. The comparable surfaces are covered in AWS Bedrock DLP and Azure AI Foundry DLP.
The record
decision_id: d-3e82d5, recorded at 2026-08-14T08:34:16Zoriginating_identity: k.varga@example.comsurface: workspace_side_panel,host_app: docsgrounding_sources: drive folder-hr-2019 at org-wide scope, gmail thread-88213 at restricted scopeuser_typed_bytes: 214grounded_context_bytes: 41,880classifications: compensation on 4 spans, employee-pii on 9policy: workspace-grounding-v2,outcome: redacted
The pair of user_typed_bytes and grounded_context_bytes is the field I would put on the first slide of any internal review. A 214-byte question producing a 41KB request is the whole argument for why inspecting user input misses the point, and it is a number every organization can measure on its own traffic this week.
The share_scope on each grounding source turns a month of these records into a ranked list of over-shared items by how often they reach a model, which is a better remediation queue than a permissions export.
DeepInspect
This is the gap DeepInspect closes. DeepInspect sits as a stateless proxy on the HTTP path between your users, applications and agents and the model endpoints they call, which covers your Vertex-side applications directly and gives you a single policy definition and a single record format across every AI surface in the organization rather than one per vendor console.
Content is classified before the request is forwarded, policy is evaluated against the identity that originated it, and a per-decision record is written into storage you control rather than into a vendor's admin reporting. Enforcement is inline and fails closed.
DeepInspect does not manage your Workspace admin settings, fix your Drive sharing, or run your access review.
If your Gemini governance is a set of admin toggles and you cannot say what content those grounded requests carried, that content question is the one to answer first. Book a demo today.