Google Agentspace Audit Logs: Evidence for Agent Answers
Google Agentspace audit logs should join the originating employee or agent, retrieved enterprise sources, model route, and authorization decision for one answer. This article maps provider and source events to the independent HTTP request record needed to reconstruct model egress during a security review.
TL;DR
- Google Agentspace audit logs should link the requesting identity with retrieval-source references and the policy decision for each agent answer.
Provider and source-system events establish administration and retrieval context, while a per-decision HTTP record establishes the egress authorization decision. A quarterly reconstruction test should prove that a reviewer can rebuild one answer request from its correlation ID.
The answer path needs a correlation key
An agent answer can retrieve documents from enterprise systems before calling a model. It can then return a concise response in seconds. Its audit trail crosses more than one record domain. A source system knows its document ID and entitlement state. The application knows the request flow. The provider may retain service-level activity. The security program needs a correlation key that joins those facts without relying on a human memory of the incident.
Google Cloud's AI security guidance is useful provider-side context. NIST AI RMF 1.0 provides the governance vocabulary for documenting AI context and handling. In a review room, a single request ID written on a paper pad beside the keyboard should be enough to find the requested answer and the decision that governed it.
The record begins with the originating person or agent. It also records the relay service and selected model route. Add the requested operation, retrieved source references, classification, policy outcome, and timestamp. A model response alone cannot answer those questions after an incident.
Provider, source, and request records
Provider administration records can show configuration or service activity. Source-system events can establish what material was eligible for retrieval. The request-layer record establishes whether the assembled context was allowed to reach a model for this identity and route under a policy active at that time.
Keep those roles distinct. A source event proves that a document existed and that a connector could retrieve it. It does not prove that the document's contents entered a specific model request. A provider activity event may show service use. It does not necessarily carry the employee identity or enterprise policy evaluation that drove the request.
I distrust a logging design that calls every export an audit trail. A real trail must let a second engineer reconstruct one decision without reading every system's event stream or contacting the person who built the integration.
Identity and delegated agent actions
An agent can act on behalf of an employee while an application relay makes the HTTP call. Preserve the originator and agent identity as separate fields. The requested action and relay identity need their own fields too. This supports a direct answer when a reviewer asks who authorized the agent to send a particular context to a model.
The NIST AI agent identity and authorization project identifies agent identity and delegated authority alongside action lineage. The audit design should keep those distinctions visible. A shared service credential gives an operations team a system name. It cannot replace evidence about the person or agent acting through that service.
Google workspace administration, source connector permissions, and local browser activity are outside DeepInspect's HTTP boundary. Endpoint posture, credential storage, and provider-internal service controls are outside it too. They still need controls and evidence. Clear ownership prevents the model gateway from becoming a fictional answer to every security question.
The model egress decision
The HTTP AI request boundary appears after application or agent context is available and before the assembled request reaches an LLM endpoint. A policy layer can evaluate the supplied identity and route. It can also use data classification and the requested operation. It can allow the request or stop it with redaction or denial, then create a record that preserves its decision.
That record complements retrieval controls. Retrieval eligibility decides which source material is available. Egress policy decides whether assembled material may travel to a model route under the relevant policy. The two decisions occur at different points and need separate testing.
AI data classification explains an input needed for egress policy. AI agent authorization covers the identity and delegated-authority question that the request record must preserve.
A reconstruction test
Each quarter, use an approved test identity and controlled source content to make one permitted request and one denied request. Retrieve the caller or agent identity and source references for both events. Then retrieve the relay details, route, classification, policy outcome, and time. Set a clear retrieval window, such as one business hour, and record any field that cannot be recovered.
This test exposes missing joins before an assessor or incident commander needs the evidence. It also gives platform, IAM, and source-system owners a precise repair target. A generic statement that logging is enabled provides little help when a customer asks for the history of one answer.
DeepInspect
DeepInspect is a stateless proxy between authenticated users or agents and HTTP LLM endpoints. It evaluates application-supplied identity and route before checking prompt classification against policy. It then produces a per-decision audit record outside the calling application's write path.
For Google Agentspace-related flows, source systems and provider controls retain their own records. DeepInspect supplies independent evidence about the request-level authorization decision at model egress. This preserves an honest boundary while giving a reviewer a concrete record to retrieve.
Book a technical deep dive at deepinspect.ai.