There is a tension at the heart of a sovereign AI assistant. The whole promise is that your knowledge stays inside your building — your model runs on your own hardware, your data never leaves. But a customer-facing assistant has to be reachable from the public internet, always on, fast everywhere, and hardened against the kind of attacks that any public endpoint attracts. Reachable and private are pulling in opposite directions.
Cloud Shield is how Wegenty resolves that tension. It is a highly available cloud edge that brokers public connections to the AI cores running inside customers' networks — without ever exposing a core directly, and without the customer ever owning a single piece of that public-facing work. This post walks through the architecture for the technically curious buyer: not the deep operations runbook, but enough of the shape that you can see why a public AI can stay sovereign.
The one idea to hold onto: the core is never reachable from the outside. Everything below is in service of that.
The problem with the obvious approach
The obvious way to put a private server online is to open a port. You put the AI core on the network, poke a hole in the firewall, map an inbound rule, point a domain at it, and hope your defences hold. Every one of those steps is a new way in. An open inbound port is a standing invitation — it exists whether or not anyone you trust is using it, and it is exactly what an attacker scans for.
Cloud Shield does the opposite. The customer's network opens no inbound ports at all. There is no public endpoint on the core, no inbound firewall rule, nothing for an attacker to find. The core stays as private as it was the day before you connected it. The way that works is the first and most important piece of the architecture.
The connector tunnel: the box dials out
Inside the customer network, each AI core runs a small connector daemon. Instead of waiting to be reached, the connector reaches out. It dials a persistent, encrypted connection to Cloud Shield and holds it open — the same pattern that makes tools like Cloudflare Tunnel and Tailscale safe to run behind a closed firewall.
This is the connector tunnel, and the direction is the whole point:
- Outbound only. The connection is established from the customer network. Cloud Shield never initiates a connection into it. The customer's deny-by-default firewall stays closed — outbound traffic is normal and expected; inbound holes are the dangerous part, and there are none.
- Encrypted and mutually authenticated. The tunnel runs over QUIC with TLS 1.3. Every connector carries its own certificate, scoped to one tenant and one core. The tunnel is provably tied to exactly one core of exactly one customer — Cloud Shield knows precisely who is on the other end, and a stranger cannot impersonate a core.
- Self-healing. Connectors send a regular heartbeat. If a core goes offline, its tunnel is drained and traffic stops routing to it. Connectivity follows the cores that are actually healthy.
The property that makes this safe is almost boringly simple: connectivity is offered by the core, never imposed on it. The customer is always the one who dials out. There is no door to leave unlocked because there is no door.
Many cores per tenant
A single customer is not limited to one core. A tenant can register many connectors, and Cloud Shield can treat them however the customer needs:
- As a high-availability pool. Several interchangeable cores share the load, and if one connector drops, Cloud Shield fails over to the others automatically. This is how you get redundancy and throughput without any single machine being a point of failure.
- As individually addressable cores. Each core can have its own stable identity — say a core in one region versus another, or one tuned to a different model or data-residency requirement — so a caller can target exactly the one it means.
- As a mix of both. Routing is resolved at the edge from a live registry of who is connected: tenant, to set of cores, to a selection policy, with unhealthy cores drained out automatically.
This pairs naturally with the connection artifact — the small file that names an instance and its scopes. The artifact says which instance; the tunnel is how that instance is actually reached.
The public edge: AWS, hardened
On the public side, traffic arrives at a cloud edge built on AWS and designed to absorb the internet's hostility before anything reaches a core. A request lands at a content-delivery and firewall layer — a CDN, a web application firewall, and managed DDoS protection — terminates TLS there, and only then is it allowed deeper. Public traffic and customer administration run as two separate planes, with their own ingress, their own identities, and their own permissions, so the people managing a tenant and the end users talking to its assistant never share a path.
Inside, the architecture is split into zones: a public zone that holds only the edge load balancers, a private compute zone with no route to the internet at all, and a private data zone for state. The compute that actually handles requests has no way to reach out to the open internet on its own — it can only do its job and answer back down the tunnel.
Scale-to-zero: you pay when it is used
Here is the part that matters to the economics. The request-handling compute is containerised and scales to zero. When a tenant is idle — no one is talking to its assistant — its compute drops to nothing. The first request warms it back up on demand. (This is what scale-to-zero means in practice.)
The effect: an idle tenant costs essentially nothing in compute. You are not renting a server that sits warm and bored overnight; capacity follows actual demand, request by request. Only the minimal connectivity layer — the tunnel ingress that keeps cores connected even when no one is asking anything — stays warm, and that is deliberately cheap. It is the price of always available, and it is small.
For a fleet of customers who each get busy at different times, this is the difference between a cost that grows with usage and one that grows with the number of doors you left propped open. Cloud Shield grows with usage.
Always on, even when something breaks
Sovereign and compliant are table stakes; an assistant your customers reach also has to stay up. Cloud Shield runs active-active across multiple availability zones — at least two independent data-centre zones, with no single point of failure on the request path. The proxies that route traffic hold no state of their own, so recovery is instant: if a zone has trouble, traffic simply flows through the others. State lives in managed, replicated stores. And the planes are isolated by design, so a problem in the customer-admin plane can never take down the live assistant your customers are talking to.
The default home for all of this is an EU region — which is the point. The resilience story and the sovereignty story are the same story: your assistant stays up, and it stays inside the jurisdiction you chose.
Zero-trust, and a record of every connection
Cloud Shield treats every request as untrusted until it proves otherwise. The controls layer from the public edge all the way down to the tunnel: a firewall and DDoS protection at the perimeter; authentication and authorisation for every user and admin; mutual TLS on the path to the core; per-tenant isolation so one customer's traffic, identities, keys and secrets can never reach another's.
And every public connection is logged — who connected, as which identity, what was decided, and where it was routed. That record is not an afterthought; it is the audit substrate the whole compliance story rests on. It is what lets a customer answer, with evidence, the question regulators increasingly ask: who reached your AI, and when? The control set maps cleanly onto the frameworks auditors recognise, and it complements the platform's alignment with the DSGVO and the EU-KI-Verordnung (AI Act).
100% infrastructure-as-code
One more property, because it is what makes the rest trustworthy at scale. Cloud Shield is provisioned entirely as infrastructure-as-code — there are no hand-clicked changes in a console somewhere. The whole edge, every security module, every per-tenant boundary, is described in version-controlled definitions, reviewed before it ships, and checked against policy automatically. Onboarding a new customer is a parameterised, repeatable apply, not a bespoke project that someone might get subtly wrong.
For a buyer, the practical meaning is consistency: the isolation and the controls you were promised are not a manual checklist someone runs and hopes to get right each time. They are codified, reviewed, and reproduced identically for every tenant.
Back to the trust boundary
Step back and the shape is clear. Cloud Shield gives a customer a public, compliant, always-on edge for their AI assistant — without the customer owning that work, and without punching a single hole in their network. The core stays private. The connection is dialled outward. The public edge absorbs the hostility, isolates every tenant, logs every connection, and costs money only when someone is actually being served.
None of this changes what the assistant is allowed to say. That is governed elsewhere, by the governed projection that keeps the public agent a strict, one-directional subset of your internal knowledge. Cloud Shield is the connection-layer counterpart to that boundary: the projection decides what may be seen; Cloud Shield makes reaching it public and safe at the same time. Together they are why a public-facing AI can still be a sovereign one.
If you want the bigger picture of how governance flows end to end, the platform page lays it out. If you would rather read the parts that are open and verify the boundary in source, start with the open-source overview — Cloud Shield is the one closed, operated component over a system that is otherwise yours to audit. And when you want to talk through what a deployment looks like for your network, get in touch; we will walk you through it.