Vertex AI Agent Engine became GA in early 2026 and is now Google’s recommended runtime for production agentic AI on GCP. Combined with the broader Google Cloud control plane — Org Policy, VPC-SC, Assured Workloads, Sovereign Controls — it gives you an excellent data plane. What it doesn’t give you is the agent’s decision plane.

This article walks through the specific gaps an EU/UK regulated deployer needs to close, where the gaps live, and how to close them without forking the runtime.

What Vertex AI Agent Engine ships #

To be clear about what’s already in the box:

  • Vertex AI Agent Engine itself. The managed runtime. Spins up agent invocations on GCP-managed compute, scales them, handles the session lifecycle.
  • ADK as the developer surface. The Java SDK and runtime that Agent Engine uses underneath.
  • Vertex AI Session Service. Managed session storage.
  • Vertex AI Memory. Managed long-term memory for agents.
  • Vertex AI Model Registry. Inventory of models with metadata.
  • Integration with Assured Workloads. Region-pinning, control enforcement, audit-log integration.
  • Cloud Audit Logs. Admin Activity, Data Access, Policy Denied.
  • CMEK / EKM. Customer-managed key encryption.

That’s a strong foundation. Most of what an EU AI Act Article 32 “security of processing” obligation expects is already there at the data-plane level.

What’s missing #

Where the gaps live, in priority order for an EU/UK regulated deployer:

Gap 1: Purpose limitation at the agent’s tool dispatch #

Cloud Audit Logs show you who invoked the agent. They don’t show you the purpose the invocation was authorised for, or whether the tool the agent picked was in-scope for that purpose. GDPR Article 5(1)(b) needs this. No data-plane control catches it.

Where to close. The ADK BeforeToolCallback seam. A plugin reads the Principal’s purpose claim, the agent’s registered purposes, the tool’s authorised purposes, and denies if they don’t intersect.

Gap 2: Audit envelope shape #

Cloud Audit Logs are key-value structured logs with GCP-defined fields. They don’t include the matched policy clause text, the framework citation, the resolved jurisdiction at the application level, the model-risk tier, or the hash-chain link to the previous event. An external auditor reviewing your EU AI Act Article 12 recordkeeping needs all of these.

Where to close. An audit plugin on the AfterAgentCallback, AfterToolCallback, AfterModelCallback hooks. The plugin emits a structured RegulusEvent with all the fields, hash-chained to the previous event in scope.

Gap 3: Dual-control on high-risk operations #

The kill-switch primitive in Vertex (you can pause an agent at the Agent Engine level) is single-control. EU AI Act Article 14 (human oversight) and FCA / PRA expectations for high-risk operations expect dual control on the kill switch itself.

Where to close. A kill-switch plugin on the BeforeAgentCallback hook, requiring two Principals with the tier-authority claim to engage. The engagement event itself feeds the audit chain.

Gap 4: Residency fail-closed on memory writes #

VPC-SC enforces network-perimeter residency at the project/folder level. But for agent-specific residency rules (this agent’s memory writes must stay in europe-west2 even if the project allows broader writes), the data-plane control doesn’t have the agent’s context.

Where to close. A RegulusFirestoreMemoryService that extends FirestoreMemoryService and checks the resolved region against the active profile’s allowed set before every write. Fail-closed if the region isn’t allowed.

Gap 5: Model-risk tier evidence #

Vertex Model Registry tracks models with metadata. But the tier classification (Tier 1 informational, Tier 2 customer-affecting, Tier 3 material customer impact) and the validation evidence pointer are deployer-defined fields that Vertex doesn’t manage.

Where to close. A model-risk plugin on the BeforeModelCallback hook. Reads the tier from a registered model registry; gates tier-3 invocations through HITL; emits framework-cited audit events.

Gap 6: GRC integration #

Cloud Logging is structured logs. ServiceNow IRM, OneTrust AI Governance, MetricStream all expect specific evidence-envelope formats with framework citations attached. Cloud Logging events don’t carry those.

Where to close. A governance-evidence plugin on the AfterAgentCallback that routes signed envelopes to the GRC adapter of choice.

What “closing the gaps” looks like in wiring #

The closing-the-gaps wiring is a Spring Boot starter and two Maven dependencies. Three lines effectively:

  1. implementation("com.neullabs:regulus-ai-adk-plugins") — all 8 plugins.
  2. implementation("com.neullabs:regulus-ai-adk-services") — the service extensions for Vertex/Firestore/GCS.
  3. implementation("com.neullabs:regulus-ai-grc-servicenow") — your chosen GRC adapter.

Then App.builder().plugins(RegulusPlugins.builder().profile("eu-ai-act").build()) in your agent setup.

No fork. The Vertex AI Agent Engine runtime is unchanged. ADK is unchanged. Google’s session, memory, artifact services are wrapped (not replaced) by Regulus’s extensions, so when Google ships new behaviour in those services it continues to work.

What this doesn’t replace #

Three things Vertex / GCP keeps doing that Regulus doesn’t touch:

  • The IAM model. Authorisation to invoke the agent at all is GCP IAM. Regulus’s policy plugin handles the application-level authorisation (purpose, tier, residency); IAM handles the infrastructure-level authorisation.
  • VPC-SC and Assured Workloads. Project/folder-level network and region controls stay where they are. Regulus’s residency plugin is the per-agent overlay, not a replacement.
  • Cloud Audit Logs. Continue to flow as the IAM and data-access audit substrate. Regulus’s audit chain is the application-level evidence — different consumers (governance team, auditor) than Cloud Audit Logs’ typical security-operations audience.

End-to-end #

After closing the gaps, an agent running on Vertex AI Agent Engine with Regulus emits two parallel evidence streams:

  • Cloud Audit Logs — IAM, data access, infra policy.
  • Regulus audit chain — application-level decisions, policy citations, framework references, hash chained.

The two reconcile naturally. Cloud Audit Logs tells your security team that a service account accessed Vertex at 22:14Z. The Regulus chain tells your DPO why that invocation was authorised (purpose = CREDIT_DECISION), what policy clause governed it (fca-sysc-4.1.7), and why the agent denied a downstream tool call (gdpr:Article-5(1)(b) purpose mismatch).

For more, see the architecture overview and the ADK plugin SPI deep-dive.