For solution architects
The agent-layer control plane that sits where Assured Workloads stops.
Google's data-layer control plane (Org Policy + VPC-SC + Assured Workloads + Sovereign Controls) is excellent. The agent layer doesn't have a default. Regulus is one answer — shaped the same way, plugged into the runtime's own extension contract.
The architecture move
Regulus is shaped like the rest of GCP's control planes: a decision plane separate from the data plane, with the seams between them explicit and audit-emitting. The agent runtime (ADK) is the workload. Regulus is the control surface.
Concretely: every state-changing tool call routes through the
Regulus policy plugin's BeforeToolCallback. The
decision is fail-closed. The decision lands as a structured event
in the hash-chained audit envelope. The envelope routes to your
GRC tool of choice via a configured adapter. The cycle is
observable, reversible, and offline-verifiable.
Six design principles you'll see in the code
- One canonical Principal. Adapters mint a single internal primitive. No raw OIDC / SAML / LDAP shapes leak past the IdentityAdapter boundary.
- Plugins as
BasePluginimplementations, not aspects. ADK's documented extension contract. No bytecode weaving. No magic. - Service extensions wrap Google-shipped impls.
RegulusVertexAiSessionService extends VertexAiSessionService. The underlying behaviour is intact; Regulus adds gating at the read/write seams. - Fail-closed by default. Residency, policy, kill-switch — every Regulus decision that can fail does so by denying, not allowing.
- Audit by construction. Every plugin's decision is observable in the same envelope shape. The audit chain is the substrate, not an afterthought.
- Frameworks as composable profiles. Regulation YAML at runtime, not Java code at compile time. Add a regulation = drop a YAML in.
The cross-org case — A2A with RFC 9421
Most regulated AI agents will eventually call other regulated
agents. ADK's A2A protocol is the substrate. Regulus wraps the
envelope with RFC 9421 HTTP Message Signatures over
(@method, @target-uri, @body, @created), plus a
replay-protection nonce window. Cross-org trust becomes a
cryptographic property, not a network property. Eve in the middle
can't replay.
Where Regulus fits in your architecture
- Above the ADK runtime, plugged into its extension SPI.
- Below your domain logic — your agent's prompts, your tool implementations.
- Beside Vertex AI Agent Engine — wraps the official session/memory/artifact services.
- Routing to your GRC tool (ServiceNow IRM / OneTrust / MetricStream / generic webhook).
- Independent of your LLM provider — the model behind ADK can be Gemini, Claude via Vertex, GPT via OpenAI, or an open-weight model on your own infrastructure.
What an architecture-review committee will ask
- "How does this affect our existing IAM model?" Adapters mint a canonical Principal from your existing IdP. No new identity store.
- "What's the failure mode if Regulus is unreachable?" Regulus runs in-process; there's no out-of-band call to a Regulus server. Failure of the framework means failure of the agent — the design is intentionally fate-shared with the runtime.
- "How does this scale?" Plugin callbacks are microseconds. Hash-chain writes are under 0.5 ms on local SSD. The dominant cost remains the model invocation.
- "What's our exit story?" Plugins compose with ADK; removing Regulus means removing the plugins from the App builder. The agent still runs. The compliance evidence stops being produced.
Where to start
- How it works — full architecture page with the control-plane diagram.
- Security architecture — Principal model, IdentityAdapter SPI, RFC 9421 A2A signing.
- vs Building in-house — what you're replacing if you've already started.