Architecture-specific review
Google Cloud Vertex AI security review
A secure model endpoint does not establish that the application around it is safe to ship. Review who can invoke the model, which data enters the prompt, what the answer can influence, and the controls demonstrated by the implementation.
Start an AI security review →Review scope
What the reviewer needs to establish
Scope the actual application and its deployment. VPC Service Controls or a safety filter is a useful control, but neither proves that grounded documents are authorized, agent actions are bounded, or a human can defend the decision.
Identity and invocation
Which service accounts and users can invoke the Vertex AI endpoint? Where are permissions checked before a user request becomes a model request?
Evidence to request: IAM policy bindings, service-account configuration and impersonation chains, application authorization logic, and the route from originating user to model call.
Network and data boundary
Is access to the endpoint restricted as intended, and where can prompts, responses and grounded content travel?
Evidence to request: VPC Service Controls perimeter, Private Service Connect and DNS design where applicable, data-flow diagram, logging destinations and retention settings.
Grounding and prompt assembly
Can a document from a lower-trust source inject instructions or expose content the requester should not see?
Evidence to request: Grounding and retrieval design (Vertex AI Search / RAG Engine), source labels, access-filter enforcement, prompt assembly code and tests using adversarial documents.
Tools and consequential actions
Can the assistant call a downstream API or change a business record? Whose authority does that call use, and which actions require approval?
Evidence to request: Function-calling and extension definitions, server-side authorization, delegated identity or service-account permissions, approval gate and audit trail.
Response handling and decision
Which risks are covered by safety filters and application checks, which remain open, and who signs off the residual risk?
Evidence to request: Deployed safety-filter configuration, application tests, open control gaps, accountable owners, review conditions and a dated clearance record.
Architecture example
Follow authority and data end to end
A model endpoint is one component. The security decision also depends on the identity that calls it, the data it receives, the actions it can trigger, and who accepts the remaining risk.
For an internal support copilot: employee identity → application authorization → grounded ticket and knowledge base content → Vertex AI (Gemini) → suggested response or ticket action. Review the access check at grounding and again before any ticket update; the model response is never the authorization decision.
From review to decision
Describe the system, confirm its architecture, examine threats and required controls, attach evidence, and record a human clearance decision. Unknown or missing evidence remains visible; it is not treated as a passed control.
Read the review methodology →