Glean DLP: The Knowledge Graph Holds Content Nobody Ever Wrote Down
Glean indexes documents and also builds a knowledge graph over people, teams, projects and activity signals. That derived layer contains inferences no document states, and those inferences become retrieval context in prompts. Add Glean Agents taking actions across connected systems and the surface widens again. This piece separates the document index from the derived graph, explains why the agent action path needs different controls from the answer path, and sets out where classification and per-decision records belong.
Ask an enterprise assistant who works on the payments migration and it names six people, ranks them by involvement, and links the four documents that justify the ranking.
No document in the company says those six people work on the payments migration. That statement was derived: from meeting attendance, from document co-authorship, from Slack channel membership, from ticket assignment. The assistant produced a fact about your organization that exists nowhere in your document store.
Glean DLP has to account for that derived layer, because it becomes prompt content like anything else, and because document-level permissions were never designed to govern an inference drawn across many documents.
Two indexes, one answer
The document index is the familiar part. Glean crawls connected sources, chunks and embeds content, and mirrors source permissions so that a user retrieves only what they could open directly. The connector list runs to Google Workspace, Microsoft 365, Slack, Jira, Confluence, Salesforce, GitHub, Zendesk and dozens more.
The knowledge graph is the part that makes the product work and the part that governance discussions skip. It holds entities for people, teams, projects, documents and their relationships, enriched with activity signals: who edited what, who attended which meeting, who is cited by whom, what a given team has been working on this quarter.
An answer draws on both. The retrieved chunks come from the document index, while ranking, personalization and entity resolution come from the graph. Both end up in the prompt sent to the model, and the graph-derived portion carries no source document and therefore inherits no source permission.
That is the structural gap worth naming. A permission model that answers "may this user open this document" has nothing to say about "may this user learn that these six people are working on this project."
Aggregation is the mechanism, not a metaphor
The classic aggregation problem in security is that a set of individually-unclassified facts can combine into a classified one. Enterprise search over a knowledge graph is that problem, industrialized.
An employee has legitimate read access to the all-hands deck, the recruiting board, the org chart, and the shared finance folder. Each of those grants is defensible on its own. Ask a question about headcount plans for a specific team and the assembled answer draws from all four and states something no single source states.
No document was over-shared and no permission was bypassed. The disclosure emerged from combination, and combination is the product's entire value proposition. This is the reason I think universal-search deployments should be preceded by an access review rather than followed by one, even though it delays the rollout by a quarter and nobody wants to hear it.
Glean Agents change the risk shape
Answering questions moves content out to a model. Agents also move content in to systems, and take actions there.
An agent that reads a support ticket, drafts a response, and posts it to Zendesk has crossed from retrieval into write. An agent that reads a Jira ticket and updates a Salesforce record has done the same. The content flowing into the write is whatever the model produced from retrieval context, and the retrieval context came from the combined corpus described above.
Two questions follow from that. Which identity performs the write, and what is the record of why. If the agent writes under a service account, the audit trail in the destination system shows the service account, and the human who triggered the run is somewhere else entirely. That is the AI agent post-authentication gap applied to enterprise search.
The authorization side of multi-step agent runs is covered in agent-to-agent authorization.
What Glean DLP has to classify
Three interventions, three shapes.
At crawl time, classification runs per chunk and produces a corpus report broken down by source and sharing scope. The output that gets acted on names the documents, not the chunks: 212 documents carrying customer PII, of which 34 are shared organization-wide. The general practice is in AI data classification.
At answer time, classification runs on the assembled prompt, which includes both retrieved chunks and graph-derived context. This is where the aggregation case is catchable, because it is the only point where the combined content exists as one object. Everything upstream sees only fragments of it.
At action time, classification runs on what the agent is about to write, plus a policy check on where it is writing and under whose authority. A drafted customer email containing content retrieved from an internal finance document is the failure mode, and it is only visible at the request that produces the draft.
The record
decision_id: d-9d41b6, recorded at 2026-08-14T12:26:38Zoriginating_identity: a.dlamini@example.com,query_id: q-2026-08-14-8820context_composition: 11 retrieved chunks, 6 graph-derived entities, 4 personalization signalsretrieved_sources: confluence page-4471 at org-wide scope, workday rec-2210 at restricted scopeclassifications: compensation on 3 spans, customer-pii on nonepolicy: search-answer-egress-v2,outcome: redacted
The context_composition block is the field that separates this from a document-only record. An investigation that shows 11 retrieved chunks and nothing else cannot explain how an answer named six people, and the graph-derived portion is exactly the part a reviewer will ask about.
For agent actions, the record carries the destination system, the write payload classification, and the originating human alongside the executing service account. Without that pair, a write in Salesforce is attributable to an integration rather than to a person.
DeepInspect
This is the gap DeepInspect closes on the request path. DeepInspect sits as a stateless proxy between your applications and agents and the model endpoints they call, so every assembled prompt is inspected before it is forwarded, whether the context came from retrieved documents, from a derived graph, or from both. Policy is evaluated against the identity that originated the query, and a per-decision record is written into storage you control.
For agent runs, the same decision point evaluates each outbound call against the originating human rather than the service account executing it, and records the action with that attribution intact. Enforcement is inline and fails closed.
DeepInspect does not crawl your sources, build your knowledge graph, or fix the document grants that made a page org-wide.
If your assistant is stating facts about your organization that no document contains, that derived layer deserves a policy of its own. Book a demo today.