Vertex AI Agent Engine Security Guide

An agent deployed on Vertex AI Agent Engine is a long-running workload with its own identity, a build pipeline that runs as root, a memory store that writes to future prompts and a code sandbox, and each of those is a separate attack surface. Google now calls the service Agent Runtime within Gemini Enterprise Agent Platform, and the API resource is still ReasoningEngine for backwards compatibility, so most teams, Terraform modules and log queries still use the older names. Our Google Vertex AI Security Guide covers the platform-wide IAM model, service agents, agent identity, audit logs and data retention. This page, for platform, cloud security and AI engineers, goes deeper on the deployed agent itself: the deployment pipeline, secrets, Sessions and Memory Bank, the code execution sandbox, private egress and the logs each component does and does not produce.

Key takeaways

The deployment pipeline is part of the agent. Build-time scripts run with root permissions and staging artifacts in Cloud Storage can be overwritten, so whoever can write to the staging bucket or the build options can change what the agent runs.
Pick the identity before the first deploy. The default Reasoning Engine Service Agent is shared by every agent in the project; production agents should use agent identity or a dedicated service account.
Memory is an input channel. Google warns that memory poisoning stores false information the agent then acts on in future sessions; scope memories per user, restrict writes with IAM Conditions and screen them with Model Armor.
Egress is yours to design. With a Private Service Connect interface and VPC Service Controls the agent has no internet path unless you build one, which is the right starting point.
Child services do not log to Cloud Logging. Sessions, Memory Bank, Code Execution and Example Store write no runtime logs, so detection relies on audit logs, agent-emitted structured logs and traces.

What you are securing

Google describes Agent Runtime as a fully managed, opinionated runtime to deploy, operate and scale agentic applications. It runs agents built with the Agent Development Kit (ADK), LangChain, LangGraph, AG2, LlamaIndex, CrewAI or custom frameworks, as long as they can be containerised and follow the runtime contract, and it supports the Agent2Agent (A2A) protocol in preview. Around the runtime sit managed services: Sessions, Memory Bank, sandboxes for code execution and computer use, Example Store and tracing through OpenTelemetry and Cloud Trace.

Component	What it holds or does	Main risk	First control
Deployed agent (`reasoningEngines` resource)	Agent code and container, scaled from `min_instances` to `max_instances`	Over-privileged runtime identity; unreviewed code changes	Agent identity or dedicated service account; deploy only from CI
Build and staging	Pickle file, `requirements.txt` and `dependencies.tar.gz` in a Cloud Storage folder; build-time shell scripts	Tampered artifacts or dependencies; scripts run as root	Locked-down staging bucket; pinned dependencies; reviewed build scripts
Environment and secrets	Environment variables, Secret Manager references	Secrets in plain variables; broad secret access	Secret Manager references with per-secret grants
Sessions	Events (conversation content and agent actions such as function calls) and short-lived state	Sensitive data retained; cross-user access	IAM Conditions; delete finished sessions
Memory Bank	LLM-extracted long-term memories per scope, inserted into future prompts	Memory poisoning, persistent prompt injection	Per-user scopes, write restrictions, TTL, Model Armor
Code execution sandbox	Isolated execution of model-written code, state kept up to 14 days	Untrusted code, data left in sandbox state	Short TTL; treat outputs as untrusted
Network egress	Default internet egress or PSC interface into your VPC	Data exfiltration, SSRF into internal services	PSC interface, VPC Service Controls, egress proxy allowlist

Identity for deployed agents

Google's access documentation describes two directions: the agent reaching other resources (agent identity, service accounts or API keys) and clients reaching the agent (IAM, plus OAuth client IDs where end users sign in and consent). A deployed agent can access whatever its service account can access.

Default service agent: service-PROJECT_NUMBER@gcp-sa-aiplatform-re.iam.gserviceaccount.com with roles/aiplatform.reasoningEngineServiceAgent. In the console it only appears when "Include Google-provided role grants" is ticked, which is why extra grants to it are often missed in reviews.
Custom service account: set with the service_account deployment parameter, using the email only. Give each agent its own account and restrict iam.serviceAccounts.actAs on it to the deployment pipeline.
Agent identity: set identity_type=AGENT_IDENTITY to give the agent a unique identity tied to its resource ID. The certificate-bound, keyless model and its lifecycle rules (new principal on redeploy, inactive bindings after delete) are covered in the Google Vertex AI Security Guide and the Agentic AI Identity Guide.
API keys for tools: stored as project-level Secret Manager secrets shareable across agents, so label them per agent and grant access per secret. Manage grants in Terraform, as Google recommends.

Deployment pipeline and secrets

Agent Runtime supports three deployment styles: an in-memory agent object packaged and staged in Cloud Storage, source files (archive no larger than 8 MB), and a prebuilt container image from Artifact Registry through container_spec. Each has security consequences.

Staging bucket integrity: Google notes that staging artifacts are overwritten if they correspond to an existing folder. Use a dedicated bucket per environment with a per-environment gcs_dir_name, give write access only to the CI identity, and enable object versioning so a tampered artifact can be traced.
Pickled agents: agent-object deployments serialise the agent as a pickle file. Pickle files execute code when loaded, so a writable staging folder is a code execution path; source-file or container deployments avoid this.
Build-time scripts: scripts in build_options run with root permissions during the container build. Keep them in the repository, review them like production code and never fetch scripts from the internet at build time.
Secrets: reference Secret Manager in the dictionary form of env_vars ({"secret": ..., "version": ...}); the list form does not support Secret Manager. Secrets must be in the same project as the agent, and the deployment-time service agent needs secretmanager.versions.access to fetch them. Never pass a secret as a plain variable, and do not set reserved names such as GOOGLE_APPLICATION_CREDENTIALS.
Encryption: CMEK is set through encryption_spec with a single-region key at creation and cannot be changed after deployment, so decide before the first production deploy.

Sessions and Memory Bank

Sessions store the chronological events of an interaction, including function calls, and Memory Bank turns conversations into long-term memories. Google's Memory Bank documentation states that each scope has an isolated collection of memories, that all sessions must have a user ID, and that retrieved memories are inserted into the agent's prompt.

Threat	How it shows up	Control
Memory poisoning (ATLAS AML.T0080.000 Memory)	A user or injected document causes false or malicious instructions to be stored and reused in later sessions	Model Armor on prompts to and from Memory Bank; topic and example tuning so only meaningful facts are kept; review of agent-written memories via `CreateMemory`
Cross-user leakage	Memories retrieved for the wrong user because scopes are shared or user IDs are guessable	Scope by agent and authenticated user; derive the user ID from the verified identity, never from the prompt
Over-broad access	Operators or other agents read every user's memories	IAM Conditions on scopes; `roles/aiplatform.memoryViewer` and `roles/aiplatform.memoryEditor` only where needed
Stale and excessive retention	Personal data kept indefinitely in memories and sessions	TTL on memories; delete sessions when conversations end

For the attack in depth see the AI Agent Memory Poisoning Guide.

Code execution sandbox

Google describes the sandbox as an isolated space to run untrusted or potentially harmful code, with a limited file system and no network access. State is kept in memory for up to 14 days with a configurable TTL, file input and output are capped at 100 MB per request or response, custom libraries cannot be installed and snapshots are not supported.

Set a short TTL: carried-over state is convenient but means data from one task is available to the next. Use the shortest TTL the workflow tolerates and a new sandbox per user or task.
Treat output as untrusted: files and results from the sandbox are produced by model-written code. Validate them before they reach another tool, a user or storage (OWASP LLM05:2025 Improper Output Handling).
Actions with side effects: Google advises that agents acting on external or critical systems should do so in a sandboxed environment with strict access control and human review. See the AI Agent Sandboxing and Code Execution Guide.

Network egress and perimeters

A Private Service Connect interface lets the agent reach VPC, on-premises or multi-cloud services privately. Agent Runtime provisions the interface in a Google-owned tenant project and connects it to a network attachment in your project, on an RFC 1918 subnet of at least /28. DNS peering lets the agent resolve names from a Cloud DNS private zone instead of hard-coded IPs.

Configuration	Internet egress	Use when
Default (no PSC interface, no perimeter)	Yes, managed by Google	Prototypes calling only public APIs
PSC interface, no VPC Service Controls	Agent traffic goes into your VPC, which has no internet path unless you add one (for example a proxy VM)	Agents that call internal services and a short list of external APIs through your proxy
PSC interface inside VPC Service Controls	Blocked by default to prevent exfiltration; restore only through a proxy in the perimeter with Cloud NAT	Agents handling regulated or sensitive data

Google's access page notes that some deployment types need VPC Service Controls ingress rules for storage.googleapis.com or artifactregistry.googleapis.com, and that VPC Service Controls is not supported with Agent Gateway. Route allowed external calls through an egress proxy with a domain allowlist so that a prompt-injected agent cannot send data anywhere it likes. See the VPC Service Controls Guide.

Logging and detection

Agent output to stdout and stderr is captured in the reasoning_engine_stdout and reasoning_engine_stderr log IDs as plain text, build output in reasoning_engine_build, and structured logs through Python logging or the Cloud Logging client appear as jsonPayload with optional trace fields. The resource type is aiplatform.googleapis.com/ReasoningEngine with labels location, resource_container and reasoning_engine_id. Google states that child resources (Sessions, Memory Bank, Code Execution and Example Store) do not write to Cloud Logging.

What to detect	Source	Signal
Unauthorised deploy or update	Admin Activity audit logs for `aiplatform.googleapis.com`	Create, update or delete of a reasoning engine by a principal other than the CI identity
Identity change	Admin Activity audit logs (IAM)	New role bindings on the agent's principal or service account; `actAs` granted to new users
Unexpected callers	Data Access audit logs (off by default; enable them)	Queries to the agent from new principals or at unusual volume
Build tampering	`reasoning_engine_build` logs; Cloud Storage audit logs on the staging bucket	Writes to staging objects outside a pipeline run; build scripts fetching remote content
Tool misuse	Agent structured logs and Cloud Trace spans	Tool calls to new destinations, spikes in tool errors, calls after Model Armor matches
Egress attempts	Proxy logs, VPC flow logs, VPC Service Controls violation logs	Denied destinations from the agent subnet; perimeter violations naming the agent's identity

Because memories and sessions produce no runtime logs, have the agent log a structured event (scope, user ID hash, memory ID, source) every time it writes a memory.

Implementation sequence

Inventory: list every reasoning engine per project with its identity, deployment style, staging location, secrets, PSC configuration and owner.
Turn on visibility first: enable Data Access audit logs for aiplatform.googleapis.com, add structured logging and tracing to agent code, and route logs to your SIEM.
Move identity: pilot agent identity or a dedicated service account on one agent, manage grants in Terraform, then migrate the rest. Keep the previous IAM state to roll back.
Lock the pipeline: CI-only deploys, staging bucket writes for the CI identity only, pinned dependencies, reviewed build scripts, Secret Manager references for every secret.
Harden memory: per-user scopes from verified identity, IAM Conditions, TTLs and Model Armor templates, starting in inspect-only mode and moving to block after tuning.
Close egress: deploy with a PSC interface, put the project in a VPC Service Controls perimeter in dry-run mode, add an allowlisting proxy, then enforce. Rollback is returning the perimeter to dry-run.
Test: run adversarial tests, as Google recommends, including memory poisoning and exfiltration through tool calls, before each major release. See the AI Agent Security Testing Checklist.

Decision guidance

Agent identity or service account: choose agent identity for new production agents, especially those calling tools or other agents, provided you can automate grants per redeploy. Choose a dedicated service account where existing tooling and reviews are built around service accounts or where preview status is unacceptable.
Agent object, source files or container: containers give the most control (scanning, signing, Artifact Registry policies) and avoid pickle files; agent objects suit quick prototypes only.

Measuring progress

Identity: percentage of production agents not running as the default Reasoning Engine Service Agent (target 100%).
Pipeline integrity: deploys or staging writes not tied to a CI run per month (target zero).
Secrets hygiene: agents with secrets in plain environment variables (target zero).
Egress control: percentage of agents handling sensitive data deployed with a PSC interface inside a perimeter.
Memory safety: Model Armor match rate on memory writes and number of memories without TTL.

Common failure patterns

One service agent for every agent: extra roles granted to the default service agent for one agent apply to all agents in the project.
Writable staging bucket: developers or other workloads can write to the staging folder, giving a route to replace the pickled agent or dependencies.
User ID from the prompt: the agent passes a user-supplied identifier to Memory Bank, so one user can read or poison another user's memories.
Open egress by default: agents with tool access and unrestricted internet egress, so a successful prompt injection can exfiltrate data in one call.

Framework mapping

Framework	Reference	Relevance
OWASP Top 10 for LLM Applications 2025	LLM01 Prompt Injection; LLM04 Data and Model Poisoning; LLM05 Improper Output Handling; LLM06 Excessive Agency	Memory poisoning, sandbox output, tool and permission scope
MITRE ATLAS	AML.T0080.000 Memory; AML.T0053 AI Agent Tool Invocation; AML.T0086 Exfiltration via AI Agent Tool Invocation; AML.M0031 Memory Hardening	Agent-specific attack and mitigation techniques
NIST SP 800-53 Rev. 5	AC-6, SC-7, SC-28, CM-14, AU-12	Least privilege, boundary protection, encryption at rest, signed components, logging
NIST CSF 2.0	PR.AA-05, PR.PS-06, DE.CM-09	Entitlements, secure development, runtime monitoring
ISO/IEC 27001:2022 Annex A	A.8.2 Privileged access rights; A.8.20 Networks security; A.8.24 Use of cryptography; A.8.15 Logging	Access, egress, encryption and logging controls

Practitioner checklist

Deploy production agents with agent identity or a dedicated service account, never the default service agent.
Manage agent principals' grants in Terraform and remove bindings when agents are deleted or redeployed.
Restrict staging bucket writes and deploy permissions to the CI identity; prefer container or source deployments.
Review build-time scripts as production code, since they run as root.
Reference every secret from Secret Manager in the dictionary form of env_vars.
Scope memories by verified user, restrict writes with IAM Conditions, set TTLs and screen with Model Armor.
Deploy sensitive agents with a PSC interface inside a VPC Service Controls perimeter and an allowlisting proxy.
Enable Data Access audit logs and log every memory write from agent code.

Vertex AI Agent Engine security guide: Securing Deployed Agents, Memory, Sandboxes and Network Egress