Can AI agent governance run in your own cloud?

Every serious conversation about governing AI agents eventually reaches the same question: where does this actually run? Not in the sense of which cloud region a marketing page names, but in the sense a security or infrastructure reviewer means it: whose infrastructure holds the identities, the policy decisions and the audit record, and what happens if that has to change.

It is a fair question to ask bluntly, and it deserves a straight answer rather than a roadmap dressed up as a feature list. So here is where SYNTHERA actually stands.

What runs today

SYNTHERA’s hosted control plane runs in the EU today. That is the real, current state: a prospective customer can be onboarded onto infrastructure that Solara operates, with identities, policy evaluation and the audit-of-record held inside EU infrastructure. This is the only path that is live for a new customer right now. Anything else described below is work in progress or further out, and the honest way to talk about either is to say so plainly rather than let “deployment options” imply a menu that already exists.

What is being built: your own Google Cloud

The next deployment model, and the one furthest along, is running the control plane inside a customer’s own Google Cloud project rather than inside Solara’s. This is not finished and not generally available, but it is the nearest of the non-hosted options to being real, for a specific reason: the pieces SYNTHERA’s control plane already depends on, a secret manager for key custody and a managed database reached through cloud identity rather than a static password, already exist inside a customer’s own Google Cloud account in the same shape they exist inside ours. Standing the control plane up there is substantially a provisioning exercise rather than a rebuild of how the system authenticates or stores its keys.

That is an important distinction from “any cloud” or “on-prem,” and it is worth being specific about why. The hard part of running this kind of control plane outside of Solara’s own infrastructure is not the application logic, it is the handful of places where the system currently assumes it is talking to one specific cloud provider’s identity and secret-management services. Google Cloud is the one place that assumption does not have to be unpicked, because the dependency is satisfied by the customer’s own account instead of ours. That is why it is the model being built first, and why we are not describing it as “multi-cloud” when it is really “the one cloud we already run on, under your account instead of ours.”

What is not offered yet, and why that matters

Four things are not available today, and we would rather name them than let silence imply otherwise.

AWS and Azure are not offered. The same identity and secret-management assumptions that Google Cloud happens to satisfy for free do not hold on either of those providers today, which means a genuine port, not a redeploy, would be required before either is real.

Kubernetes, as a target independent of any particular cloud’s managed services, is not offered. The provisioning path the control plane depends on today is tied to specific managed infrastructure rather than to a portable container orchestration target, so “we can run on your Kubernetes cluster” is not yet a true sentence, wherever that cluster happens to sit.

Air-gapped deployment is not offered. This is the deployment model regulated and high-security customers ask about most directly, and it is also the furthest from what exists today, because it requires every one of the cloud-identity and secret-management dependencies above to have a self-contained, no-outbound-network equivalent, not just a different cloud account to point at.

None of these four is a secret inside the business. They are the known, unstarted, or early-stage items on a roadmap, and the fastest way to lose a security reviewer’s trust is to let a deployment-options page imply they are closer than they are. If your own requirement is one of these four, the honest answer today is: not yet, and here is roughly what would need to be true before it could be.

What stays identical regardless of where it runs

One thing does not change between any of these models, hosted or self-run, available today or not yet built: the VAID standard underneath is the same primitive everywhere. A signed action carries the same proof-of-possession, the same capability scoping and the same lineage whether the control plane evaluating it sits in Solara’s EU infrastructure, inside a customer’s own Google Cloud project, or, eventually, somewhere else entirely. VAID itself is open source and does not require any particular deployment model to verify a signed action; what changes between deployment options is who operates the mint, the policy engine and the durable audit record behind it, and where that operator’s infrastructure physically sits.

How to actually plan around this

If your organisation’s requirement is EU hosting, that is available now. If your requirement is keeping the control plane inside your own Google Cloud account, that is the model we are building and the closest of the non-hosted paths to real, though it is not generally available yet. If your requirement is AWS, Azure, a cloud-independent Kubernetes target, or an air-gapped install, the honest answer today is that none of those exist yet, and a conversation about timing is a more useful next step than a conversation about a feature that is not there to demonstrate.

A deployment page that says “coming soon” to four different audiences at once is not actually written for any of them. The more useful version names which one of these you are, and tells you, specifically, what that means for a decision you have to make this quarter rather than next year.