Glean Audit Logs: Reconstructing an Enterprise AI Answer
Glean audit logs need to join the person who asked, the retrieved enterprise sources, the model route, and the policy decision that governed egress. This article separates source and administration events from a per-decision HTTP record that can reconstruct one AI answer during a security review.
TL;DR
- Glean audit logs should connect the requesting identity with retrieved source references and the policy decision for each answer request.
Connector permissions and source-system events establish retrieval context, while an HTTP request record establishes what crossed to a model endpoint. A review should retrieve one answer by request ID and reconstruct the authorization decision without relying on a single application log.
One answer, several records
An enterprise answer can combine a Salesforce account note, a Drive document, and a Slack thread before a model produces one paragraph. The UI may show three citations. The security record has to preserve a less tidy chain: who asked, which source objects were retrieved, which connector served them, what route carried the assembled context, and what policy evaluated the request.
Glean's Trust Center is a useful source for its published security posture. NIST AI RMF 1.0 supplies a governance framework for documentation and handling decisions. At 8:15 p.m., a reviewer with a search result on one screen and an audit export on the other needs to follow one identifier through both systems.
A source-system event can show that a document was available. A request record answers a different question: did that material leave in an AI request for this authenticated user under this policy? Both records matter. They must remain correlated rather than being treated as interchangeable logs.
Retrieval evidence needs identity context
Capture the originating employee or agent separately from connector and relay identities. A service account may collect content from a connected source. The individual who initiated an answer request can be a different principal. This distinction becomes material when a customer record appears in an answer and an incident responder needs to establish authorization.
The retrieval portion should retain source object references and connector identity. It should also record retrieval time, the sharing context, and the transaction ID that joins it to the generated answer. The HTTP decision record should add the user or agent identity supplied by the application and the LLM route. Add the data class plus the policy outcome and event time.
I would reject an audit package that presents a polished answer without an identity-linked retrieval chain. Search feels harmless while it remains a list of documents. The moment an answer assembles material across business systems, the review must prove what was eligible, what was requested, and what was allowed to leave.
The request boundary
The model-call boundary sits after retrieval and before an LLM receives assembled context. A policy layer at that point can inspect an application-supplied identity and route. It can also use the data class and requested operation. It can permit the HTTP request or stop it with redaction or denial, then create a per-decision record before the response returns.
This boundary has limits. Glean connector configuration, source permissions, and IdP group membership need controls in their own domains. Browser activity, endpoint security, and provider administration do too. An HTTP proxy cannot remove an excessive folder grant or repair a stale SSO assignment. Keeping those ownership lines visible makes a review more credible.
The NIST AI agent identity and authorization project describes identity and delegated authority alongside action lineage. An answer flow needs the same discipline. The relay service needs a distinct field. The origin and retrieval sources do too; the model request needs its own field.
Retrieval tests that expose gaps
Run a quarterly reconstruction test with an approved test identity and a controlled source document. Request one answer, record the transaction identifier, and ask a reviewer to retrieve the source references and caller identity. The reviewer should then compare the policy details with provider correlation. The test has a simple standard: a different engineer can reconstruct the decision without asking the original developer for context.
The test should include one permitted request and one blocked request. The permitted request proves that normal delivery retains enough evidence. The blocked request proves that enforcement records its own decision when content stops before it reaches the model. Those two cases reveal missing joins faster than a generic compliance questionnaire.
Keep the sample set small and repeatable. A platform owner can select a route with an approved agent. Use a test document that has a visible classification label. Record the expected policy result before the test. If the retrieved evidence conflicts with that expected result, preserve the discrepancy and assign it to the team that owns the field rather than editing an export after the fact.
AI data classification explains the context needed before a route decision. Signed audit logs for AI requests covers the integrity properties expected of the resulting evidence.
DeepInspect
DeepInspect is a stateless proxy between authenticated users or agents and HTTP LLM endpoints. It evaluates identity-bound policy and route before checking prompt-level classification, then creates a per-decision audit record outside the calling application's write path.
For Glean-related answer flows, source systems and connectors retain retrieval evidence. DeepInspect records the enforcement decision at the model-call boundary. Together, those records can reconstruct an answer request without claiming that request-level policy replaces source permissions or IAM controls.
Book a technical deep dive at deepinspect.ai.