Does Glean's shared-responsibility guide complete the assessment?

It supplies a primary statement of customer duties covering SSO and users, plus roles and connector credentials. It also covers service accounts and customer-hosted deployments. The customer must implement those duties and capture tenant-specific settings, then test retrieval and agent behavior. The customer must also retain logs and manage exceptions, then document remediation. The guide defines responsibilities. The evidence package proves operation.

Which Glean changes should trigger reassessment?

Trigger review after adding a connector and scope, or a source type, AI capability, agent, tool, model route, administrator and user group. A new hosting arrangement or retention destination also triggers review. Changes to SSO policy and source permission semantics qualify as well. The same applies to log coverage and Customer Event delivery, along with regulated-data use cases. Pair every material change with a permitted test and a restricted test.

Are Admin Audit Logs enough for user activity evidence?

Glean states that Admin Audit Logs cover administration and configuration while excluding end-user activity. Customer Event logs cover searches and clicks, along with chats and similar usage. A review usually needs both, plus source-system evidence and any model-request record created on a separate enterprise-routed path. Retention and correlation must be designed across those sources.

Where does DeepInspect fit in Glean compliance?

DeepInspect applies to authenticated HTTP model traffic deliberately routed through its gateway by an enterprise-controlled integration or agent. It can evaluate supplied identity and content class, plus destination and operation. It also evaluates policy. Native Glean queries and provider-internal model calls are outside that boundary and depend on Glean-side and customer-side evidence.

Glean Compliance: Join Connector, Identity, AI, and Audit Evidence

A Glean answer can combine a Drive policy and a Slack thread with a Salesforce note after authenticating the user through SSO. Compliance evidence has to preserve the controls around that chain: connector authority, source permission, user identity, approved AI use, query path and administrative change, along with retention. Glean documents each layer, but the customer still has to join them for one sampled activity.

I would put one answer request at the center of the review and make every control owner attach evidence to it. A certification file without that sample leaves the operating story unfinished.

TL;DR

Glean compliance spans SSO, users, connectors, source permissions, queries and AI use cases, along with logs.
Glean assigns tenant administration duties to the customer under a shared-responsibility model.
Admin logs and customer-event logs cover different activity and need an explicit retention plan.
DeepInspect sees only compatible HTTP model traffic deliberately routed through its gateway.

Shared responsibility defines the customer control file

Glean's shared-responsibility documentation assigns tenant administrators concrete duties. It calls for SSO access policies aligned with organizational requirements, MFA, trusted-location decisions, prompt removal of terminated users, role-based administration, periodic permission review and connector credential management, along with service-account discipline.

Turn each duty into a record with an owner and cadence, plus an evidence source and failure response. IAM can own SSO policy and terminated-user removal. The Glean platform team can own administrator roles and connector setup. Source owners are accountable for permissions in Drive, Slack, Jira, Salesforce, and other connected systems. Security can own query-path testing and log delivery. Records management can set retention.

The deployment model is at the top of the file. Glean documents added responsibilities for customer-hosted AWS or GCP environments. Record the hosting arrangement and region, along with the tenant identifier and contacts. Include the review date. A migration then triggers a defined reassessment.

This compliance structure extends Glean security. The security review maps connector access, identity, retrieval, and egress. Compliance attaches approval, ownership and test frequency, plus retention and remediation, to those controls.

Connector approval starts with authority and scope

Every connector should have a register entry naming the source owner, connector type, credential owner, service account, granted scopes, indexed object types, excluded locations and crawl schedule, plus last recertification. Add the business purpose and approved user population. Broad read authority may be technically required for indexing, but that authority still needs a named owner and periodic review.

Test the connector against a controlled source object. Create a document carrying a visible purple label that reads FINANCE TEST, GROUP ONLY. Grant it to a small test group, allow the connector to process it, and verify retrieval with one member and one outsider. Preserve the source permission and connector identity, plus the query timestamp and returned source reference. Include the expected result.

Source permissions are the primary retrieval control. A stale group grant can expose an object correctly according to the source while violating the customer's present policy. The remediation is with the source owner rather than the search interface.

Any connector change should reopen review. A new OAuth scope or service account can alter the data flow. An indexed object type can do the same, as can an exclusion rule or source permission model. Credential rotation evidence should show the date and account without placing secrets in the compliance repository.

The data-combination concerns in Glean DLP are relevant here. Compliance adds the approved classification scheme and the test proving that the operating process responds to combined context.

The query path provides correlation points

Glean's official query-flow documentation describes authentication through the customer's SSO provider and routing to a tenant-specific Query Endpoint. It shows search requests sent to https://<tenant_id>-be.glean.com/api/v1/search and example responses carrying tracking tokens and source identifiers, along with document metadata, visibility, and snippets.

Those fields provide a basis for a reproducible sample. Preserve the originating user and tenant endpoint, plus the request time, session or tracking token where policy permits, source references, and returned visibility metadata. Link the record to the approved use case and connector register.

A compliance team should also record what the sample leaves out. Search metadata may establish retrieval. It may lack the complete policy history for an LLM call or an agent action. An answer can include assembled context after search, while an action can write to a connected system under a service identity. Give each stage its own correlation field rather than flattening the sequence into one generic event.

My opinion is that a query screenshot should never pass as traceability because it captures only an interface state. Traceability needs identities and source references, plus event times and a join that another reviewer can repeat.

AI use cases need purpose and action boundaries

Create one use-case record for search and another for generated answers. Create a separate record for agents. Search retrieves ranked source material. Generated answers assemble context and send it through a model-processing path. Agents may call tools and write to business systems. Each operation has a different approval question and evidence set.

For an answer use case, name the eligible role and source classes, plus prohibited data classes. Record the model-processing terms and permitted output destination, then name the review owner. For an agent, add each tool and target system, along with the action type, execution identity, originating human or service, and approval threshold. A support agent allowed to draft a Zendesk response may still require a human before sending it.

Use synthetic tests for both read and write. The read test proves that an authorized user receives a source-backed answer and that an outsider receives the expected result. The write test asks a controlled agent to prepare a harmless update in a sandbox record, then verifies the originating identity and executing service account. It also verifies the tool call and approval, along with the destination event.

Document the control restrictions in direct language. Local browser behavior and endpoint posture sit with their respective controls, as do source-system grants and credential theft. The Glean approval covers the configured tenant and use case.

Log coverage and retention require an explicit design

Glean's Admin Audit Logs documentation says those logs cover administrative and configuration actions, including connector setup and connector changes, plus configuration state and global configuration. It also says they exclude end-user activity and connector crawl telemetry, along with API rate-limit metrics and usage analytics.

Glean distinguishes Admin Audit Logs from Customer Event logs, which record end-user events such as searches and clicks, along with chats. The built-in admin export uses CSV. Glean also documents ongoing delivery to customer-managed storage or a data warehouse through an account-team setup. Its stated default admin audit retention is 30 days, with longer arrangements available through Glean.

That 30-day window should drive a retention decision before the first quarterly review. Specify delivery cadence and destination, plus access restrictions and integrity checks. Define the deletion schedule separately. Test retrieval by asking an independent reviewer to find one administrator change and one end-user event.

The distinction covered in Glean audit logs is intact. Administrative history explains configuration. Customer events explain user activity. A separate model-call decision may be required for a routed HTTP path. Compliance joins the records without pretending that one log contains all three.

The evidence package reconstructs one answer or action

Choose one approved answer request. Start with the use-case approval and user and SSO state. Add the source classification and connector register entry, then the source permission. Add the query endpoint and tracking values, retrieved source references, answer or chat event, effective product configuration, and relevant administrator history. Finish with retention location and reviewer sign-off.

For an agent action, add the tool definition and permitted operation, plus the target system, originating identity and executing identity. Add the approval event and write result. The destination audit event should correlate with Glean activity without relying on the service account as the only actor.

Keep sensitive source content out of the compliance folder where a reference or hash will support correlation. The purple test label can appear in the sample because its content is synthetic. Production customer notes and employee records deserve minimization.

Run the package through a reconstruction test. Give it to a reviewer who did not configure the tenant. The reviewer should identify who asked and which sources were eligible, plus which control allowed the operation, where the event was retained, and which team owns any gap. Record the time required to answer and assign remediation for missing joins.

The HTTP boundary separates native and routed traffic

Native Glean searches and answers follow Glean's application architecture, along with connector processing and provider-internal model calls. Glean documentation and tenant configuration govern that path, supported by admin logs and customer events, plus source records and support evidence. An enterprise HTTP gateway ordinarily lacks an insertion point inside Glean's own service-to-model processing.

A separate path exists when an enterprise-built integration or adjacent agent sends an authenticated HTTP request through an enterprise-controlled service to an LLM endpoint. A compatible route can carry the originating identity and content class, plus the requested operation and model destination. It can also carry the policy version. Inline policy can then permit or deny the request. It can redact content before the model receives it.

DeepInspect covers that deliberately routed HTTP traffic. It leaves connector crawls, source permissions, SSO administration, local endpoints and Glean-native activity, along with provider operations, outside its enforcement boundary. A diagram should mark the two paths separately so a request record is never used to claim coverage over a native Glean event.

DeepInspect

DeepInspect creates an independent policy decision for compatible HTTP AI requests intentionally routed through the gateway. It evaluates application-supplied identity and role, plus content classification and operation. It also evaluates destination and current policy before the LLM receives the request.

Each result becomes a signed, tamper-evident record outside the calling application's write path. That record can join connector approval and source evidence with Glean events for an enterprise-controlled integration while preserving the ownership boundary around native Glean activity.

Book a technical deep dive at deepinspect.ai.