Google Agentspace Security: The Enterprise Answer Boundary

TL;DR

Google Agentspace security starts with source permissions and connector identity, then follows assembled enterprise context to the model route.

• For every HTTP model request, keep the originating user or agent visible through the relay. The record should also retain the data class plus the requested operation and policy outcome.

IAM and connector configuration need separate owners from source sharing. Local devices and provider administration need separate owners too. Those responsibilities should remain visible rather than being folded into a generic AI security claim.

The enterprise answer path

An enterprise answer can pull a document title from Drive. It can also pull a message from Chat and a CRM account note before it reaches a model. That answer may look like one short paragraph in a browser. The security review has to trace source entitlements and connector scope. Trace the path. It must also follow identity handoffs and assembled context. Then document the selected route and final authorization decision.

Google Cloud's AI security guidance provides provider-side security context. NIST SP 800-207 frames access as a decision based on explicit context. Put each connected system and its credential on a single diagram. Show the requesting identity, then its application relay and LLM endpoint. Do not infer the handoffs. A printed copy with the service account names circled in red is a better review artifact than an inventory that omits them.

The map should distinguish a source connector from an originating user. A connector may require broad access to index information. The backend that calls a model may use another credential. Neither credential necessarily identifies the employee or approved agent whose request produced the answer.

Source access and model egress

Source-system permissions determine what content can be retrieved. Historical groups and inherited sharing can remain active long after their owners forget the original project. An answer interface makes that old entitlement more visible because it assembles material across sources instead of requiring a person to know the file name.

Test the flow with controlled content carrying a visible classification label. Record the source permission result and connector reference. Then retain the user identity, selected model route, and transaction ID. Repeat the test after changing the source permission. The result reveals where authorization is evaluated and whether the identity is preserved into the answer flow.

Source sharing, workspace administration, and IdP groups sit outside DeepInspect's boundary. Local browser sessions, endpoint posture, and provider-internal controls do too. They require controls in their own domains. An HTTP proxy cannot remove an old Drive grant or revise a user group. Clear boundaries keep those responsibilities from disappearing into a generic AI security claim.

The HTTP AI policy decision

The relevant decision occurs after authenticated application or agent context exists and before assembled prompt content reaches an LLM endpoint. Policy can inspect application-supplied identity and route. It can also use data classification and the requested operation. It can permit the request or stop it with redaction or denial, then write a per-decision audit record that identifies the policy version and event time.

This egress decision has a separate purpose from retrieval authorization. Retrieval determines whether a source object is available. Egress policy determines whether assembled material can travel to a model route under the policy active at that moment. The controls run at different points and must both be tested.

OWASP's LLM Top 10 gives security teams a model-facing reference. AI data classification and AI agent authorization describe two inputs needed to make a request-level decision meaningful.

Evidence a reviewer can reconstruct

For each sampled answer, retain the originating identity and agent identity when present. Keep the relay service with source references, classification, and model route. Record the policy identifier, decision, timestamp, and correlation ID separately. Store the policy decision outside the calling application's own write path. That gives a reviewer a record to compare with application and provider events if their timing differs.

That record should connect the retrieval result to the outbound decision without requiring a reviewer to reconstruct the sequence from memory. The same sample can show whether a permitted source result was later blocked. It can also show whether an allowed route received content that should have stopped earlier. These records make a failed check actionable instead of leaving teams to infer the path from a final answer.

I would treat a system-wide statement that logging is enabled as a starting signal, not an audit result. A reviewer should be able to retrieve one permitted request and one denied request within a defined time window. The reason for each decision should be clear.

Run the test quarterly using an approved test identity and controlled source data. Record the expected outcome before the request. If the evidence lacks a source reference, loses the initiating identity, or has no policy outcome, route the gap to the team that owns that field. The test leaves an objective repair target.

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 produces an independent per-decision audit record for the enforcement result.

For Google Agentspace-related flows, source systems and provider controls retain their own evidence. DeepInspect governs the HTTP model request after context is assembled. That division gives platform, IAM, and security teams a concrete record to verify without assigning every surrounding control to the gateway.

Book a technical deep dive at deepinspect.ai.