Private agents. Private inference. No way out.

A privacy-first runtime for agents and inference: private models, default-deny networking, and hard isolation between tenants, so regulated buyers do not have to trust a third-party model API with their prompts.

No. What exists is a working reference architecture and PoC on AWS. This site describes the product vision; the PoC proves the hard isolation properties first. Compliance packaging and SLOs are not claimed yet.

Many finance and health-adjacent buyers refuse public model APIs regardless of contract language. Sovran's answer is structural: no path to those APIs from the agent, and a private model plane you control.

Samples tend to isolate tenants from each other while still allowing internet egress or third-party model APIs. Sovran's difference is the boundary itself: private inference, host-mediated data patterns, and egress policy as a first-class feature rather than a missing toggle.

Tier A first — contractual plus network isolation on platform-hosted AWS — with a clear path toward customer-controlled deployment (B) and, later, stronger hardware or on-prem stories (C/D). We do not present A as if it were D.

That is the target design (host-mediated I/O; the guest sees local disk only). The current ECS PoC raises the bar — no AWS SDK in the agent image, sync sidecars hold the S3 rights — but one task IAM role is still shared across containers. Removing that residual needs host mediation, and we call it out rather than paper over it.

Into the tenant's session workspace and data store, not into shared platform log groups. Operators see latency, status, and policy denials. Tenants get transcripts they can export and retain under their own policy.

Self-hosted open weights on a private plane, chosen for procurement comfort as much as capability. The PoC runs instruction-tuned Gemma 4 E2B on vLLM, on a single GPU instance, with the weights baked into the machine image so the model plane needs no internet at all — it has been booted with every egress rule revoked and still served. It has now been proven on two GPU generations in two regions, which matters mainly because it shows the model plane is not pinned to one scarce instance type. The capability gap versus frontier SaaS APIs is real; privacy is the trade a buyer is making.

Measured on the PoC's own hardware — one NVIDIA L4 (a g6.xlarge), 24GB, running Gemma 4 E2B on vLLM at its full 131k context. Numbers below are from the model host itself, so no load balancer, PrivateLink hop or agent logic is included in them.

Single stream, 256 output tokens

49 tok/s

Single stream, 2048 output tokens

47 tok/s

8 concurrent streams

366 tok/s total · 46 each

Prompt ingest (4.5k tokens)

well under a second

Cold start, zero to serving

~35 minutes

Two things stand out. Throughput is flat in answer length — 8x longer output costs under 4% — so "how long is the reply" is not a capacity question. And concurrency is close to free: eight simultaneous sessions cost about 7% each and deliver 7.4x the aggregate, so one conversation does not saturate a single GPU.

Qualitatively, at this size it is better than the parameter count suggests and clearly not frontier. Asked for a 700-word story it produced a coherent one that held its premise and landed a real ending. Asked for FizzBuzz in Python and Rust it wrote both idiomatically and correctly described why the Rust version reads differently. Given a function that concatenated user input into a SQL string, it led with the injection vulnerability. Tool calling is reliable enough that the end-to-end demo runs several tool calls per session without hand-holding.

Where it will disappoint: long-horizon reasoning, dense domain knowledge, and anything you would currently reach for a frontier model to do. The honest framing is that the architecture is model-agnostic — a larger open-weight model on a bigger GPU slots into the same private plane — and that a 24GB card capped at one instance is a proof of isolation, not a serving tier.

This is the most common extension people ask about, so to be clear up front: it is not implemented or tested in the reference architecture. What follows is the shape that fits the design rather than something we have proven.

The wrong answer is a NAT gateway. Opening general egress to reach one internal API discards the property the whole architecture exists to hold, and it is the exact "temporary" exception that never gets closed.

The shape that fits is to turn the direction around: you publish the service. In your account you put an internal load balancer in front of the system the agent needs, and expose it as your own PrivateLink endpoint service. The reference account then gets an interface endpoint in the agent tier pointing at that one named service. If the target is on-premise, your side bridges it over Direct Connect or VPN — that is your existing private path, not something the agent platform has to open.

This keeps the properties that matter: still no NAT and no internet gateway, traffic never traverses the public internet, the reachable surface is one named service rather than a route to everywhere, and you own the endpoint service — so you can revoke access without our involvement.

The honest caveats. It genuinely widens what a compromised or prompt-injected agent can reach, and that target is now inside your network, so it belongs behind the same tool allowlisting and scoping discipline as any other capability — not simply switched on. And since we have not built it, treat the diagram as a design sketch: the isolation claims we have actually tested are the ones on the PoC diagram above.

Sovran is a product of Xowit Labs (labs.xowit.com), a company registered in England and Wales (company number 17154346).

It is free. Email us at hello@sovran.uk and we will share sample Terraform for the multi-account reference architecture, plus operator notes to apply it, demo the isolation, and tear it down. Mentioning what you are building is welcome but optional — we are curious what people want this for, not vetting you.

Do not open general internet egress from the agent or model tier. Promote dependencies through a private artifact path — S3 used as a static index or registry. For Python, host a simple package index or wheels on S3 and install only from that URL. Same rule as model weights: every artifact enters through a controlled, allowlisted store, never pip or Docker Hub at runtime from the trusted boundary.

For containers this is no longer a suggestion — the PoC does it. A container pull is only two HTTP GETs, for a manifest and some blobs, and S3 can serve both as static objects. So the images are laid out as a read-only registry in a bucket the account owns, readable only through the VPC endpoint, and the registry service is gone entirely: no ECR repositories, no registry endpoints, and no registry permissions on the execution role, because an anonymous pull needs none.

The reason to bother was never the saving. While images came from a managed registry, the storage policy had to keep allowing a bucket owned by the cloud provider — an object store we can neither inspect nor reason about, sitting inside the one egress path the agent still has. Serving our own images closed that: the policy now names this account's buckets and nothing else. The cost is stated plainly in the repo — anything running in the VPC can read the image layers — which is a real trade, not a free win.

• Python packages on S3 (simple index)
• S3 as a container registry