Google Agentspace DLP: A No-Code Agent Builder Puts Data-Movement Design in Non-Engineer Hands
Google Agentspace lets a business user assemble an agent from connectors, a model and a set of actions without writing code. That moves the decision about which data reaches a model from an engineering review into a self-service form. This piece walks the connector, action and agent-build paths, explains why agent proliferation is the governance problem rather than any single agent, and sets out where classification and per-decision records belong.
A regional sales manager builds an agent in an afternoon. It connects to Salesforce and Google Drive, reads opportunity records and the pricing folder, drafts customer follow-ups, and posts them as Gmail drafts. It works well enough that four colleagues copy it within a fortnight.
No engineer reviewed the design, and no architecture diagram contains it. It was assembled through a form, and the form worked exactly as designed.
Google Agentspace DLP is a governance problem about who gets to decide which data reaches a model, and the answer in a self-service product is everyone with a licence.
Three paths, and the third is the new one
Connector indexing brings enterprise content into a searchable corpus. Agentspace connects to Google Workspace, and to third-party sources including Jira, ServiceNow, Salesforce, SharePoint and Confluence. The indexing job embeds what the connector credentials can reach, on a schedule, at bulk volume. This is the same profile as every other enterprise retrieval pipeline.
Answer generation assembles retrieved content into a prompt and sends it to a Gemini model. Content from several source systems converges into one request.
Agent actions are the path with no analogue in a search product. An agent can write: create a ticket, update a record, send a draft, post a message. The content of that write was produced by a model from retrieval context, and it lands in a system of record.
The first two paths move data out to a model. The third moves model output into your business systems, and the review discipline applied to the third is usually whatever the person who built the agent thought about for a minute.
Proliferation is the governance problem
A single agent is reviewable. Two hundred agents built by ninety people over six months is a different object.
Each one embeds a data-movement decision: which connectors it reads, which fields it pulls, what it puts in the prompt, where it writes. Those decisions were made in a builder UI by someone optimizing for whether the agent produces useful output, which is the right thing for them to optimize for and the wrong place for a data-classification judgment to be made silently.
The failure mode is mundane. An agent built to draft customer emails is given access to the internal pricing folder because that is where the discount rules live, and the model occasionally includes an internal margin figure in a draft that a human then sends. Nothing was hacked. A connector was added to a form field.
I would rather see an organization ship twenty reviewed agents than two hundred unreviewed ones, and I am aware that is an unpopular position in a year when agent count is being reported as a KPI.
Service accounts and the identity question
Agentspace supports agents acting with end-user credentials and agents acting with their own service identity, and which one a given agent uses depends on how it was configured.
When an agent reads under its own service account, the permission evaluated at the source system is the service account's, which has to be broad enough to serve every user of that agent. A restriction that would have applied to the individual asking evaluates against something else entirely. That is the AI agent post-authentication gap in its most common form.
When an agent writes under a service account, the destination system's audit trail records the service account. Six weeks later, working out which human caused a specific Salesforce record update means correlating timestamps across three systems, if the logs still exist.
Ask, for each deployed agent, which identity it reads under and which it writes under. That inventory is usually shorter to produce than people expect and more alarming than they expect.
What Agentspace DLP has to classify
At index time, classification runs per chunk and produces a corpus report by source and sharing scope. The practice is covered in AI data classification.
At prompt time, classification runs on the assembled request, which is the only point where retrieval content from several connectors exists as one object. This is prompt-level DLP applied to an agent's context window.
At action time, classification runs on the payload the agent is about to write, evaluated against the destination. Internal margin data in an outbound customer email draft is a policy violation defined by where it is going, and the destination is only known at the moment of the action.
The dimension worth adding on top is the agent itself. Policy that says which classes a given agent may handle, attached to the agent rather than to the user, is what makes two hundred agents governable, because it turns an unbounded review problem into a bounded set of agent-level policies.
The record
decision_id: d-4b7c30, recorded at 2026-08-14T16:11:52Zoriginating_identity: n.baptiste@example.comagent_id: agent-emea-followups,agent_owner: n.baptiste@example.comacting_principal: sa-agentspace-emea@example.iam.gserviceaccount.comstep: action, distinguishing a write from a retrievalconnectors_read: salesforce, google-driveaction_destination: gmail:draft, an external-facing surfaceclassifications: internal-pricing on 2 spans, customer-pii on 5policy: agent-action-egress-v1,outcome: blockedreason: internal-pricing class bound for an external-facing destination
The agent_id and agent_owner pair is what makes a self-service estate governable. Aggregate a month of records by agent and the output ranks two hundred agents by how much sensitive content each one moves, which is the list a security team can actually work through. Without it, every record attributes back to one shared service account and the estate is one undifferentiated blob.
The action_destination field is what separates an internal summary from an outbound customer email, and that distinction carries most of the policy weight.
DeepInspect
This is the gap DeepInspect closes on the request path. DeepInspect sits as a stateless proxy between your agents and the model endpoints they call, so the assembled prompt and the model output that becomes an action are both inspected regardless of who built the agent or which builder UI produced it. Policy is evaluated against the identity that originated the request, and a per-decision record is written into storage you control.
Because the decision point sits below the agent, a new agent built this afternoon by someone in sales is governed by the same policy as the ones engineering reviewed last quarter, with no onboarding step and nothing for the builder to configure. Enforcement is inline and fails closed.
DeepInspect does not build your agents, manage your connectors, or set your Google Cloud IAM bindings.
If your agent count is growing faster than your review capacity, enforcement below the agents is what scales. Book a demo today.