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

  1. One canonical Principal. Adapters mint a single internal primitive. No raw OIDC / SAML / LDAP shapes leak past the IdentityAdapter boundary.
  2. Plugins as BasePlugin implementations, not aspects. ADK's documented extension contract. No bytecode weaving. No magic.
  3. Service extensions wrap Google-shipped impls. RegulusVertexAiSessionService extends VertexAiSessionService. The underlying behaviour is intact; Regulus adds gating at the read/write seams.
  4. Fail-closed by default. Residency, policy, kill-switch — every Regulus decision that can fail does so by denying, not allowing.
  5. Audit by construction. Every plugin's decision is observable in the same envelope shape. The audit chain is the substrate, not an afterthought.
  6. 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.

Hash-chained audit envelope from Regulus Three sequential blocks, each carrying a SHA-256 hash of the previous block. The middle block is expanded to show the event metadata fields. Event N−1 tool.call: pricing.query policy: ALLOW prev: ab12… hash: c4f3… Event N — RegulusEvent ts 2026-06-01T22:14:03Z agent credit-decision-eu tool ledger.book_transfer policy DENY · gdpr-art-22 framework nist-ai-rmf · MANAGE-2.1 jurisdiction eu · europe-west3 principal sub:dipankar · tenant:42 prev_hash c4f3a91b… hash e9d4f72a… Event N+1 a2a.send: peer.eu-1 policy: ALLOW prev: e9d4… hash: 7a82…

Where Regulus fits in your architecture

What an architecture-review committee will ask

  1. "How does this affect our existing IAM model?" Adapters mint a canonical Principal from your existing IdP. No new identity store.
  2. "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.
  3. "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.
  4. "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