Back to blog
Technology

One Client, One Server — The Security Model That AI Infrastructure Actually Needs

2026-06-18|7 min read

Most security claims in AI infrastructure are trust statements dressed as architecture. "We don't train on your data." "Your prompts are private." "Logs are anonymized." These are policies. Policies can be changed, misconfigured, or quietly violated by a junior engineer running a debug script on the wrong cluster.

Real isolation is not a policy. It is a wall.

Shared-tenancy AI is structurally risky

When multiple clients share the same inference cluster, four failure modes are baked in:

  • Training contamination. Fine-tuning runs that touch one tenant's data routinely leak signal into model weights used by others.
  • Log mixing. Observability pipelines aggregate prompts, completions, and errors into shared sinks. One Splunk query and another client's payload appears.
  • Inference leakage. KV-cache reuse, prefix sharing, and speculative decoding optimizations have all produced documented cross-tenant leaks.
  • Backup overlap. Snapshot storage typically holds many tenants in the same volume. Restore the wrong snapshot, expose the wrong data.

None of these are bugs. They are the price of shared infrastructure. You can mitigate them with encryption, namespacing, and access control, but you cannot eliminate them as long as bytes from two clients ever sit on the same machine.

One client, one physical server

S.V.I. solves the problem by removing the shared substrate entirely. Each enterprise client runs on dedicated physical hardware. Not a dedicated VM. Not a dedicated namespace. A dedicated machine.

Client data never overlaps with another client's data — not in training, not in inference, not in logs, not in backups. There is no cluster to leak across, because there is no cluster. When a client signs an NDA with us, the isolation is enforced by the fact that the other party's bytes are physically somewhere else, on hardware they have never touched.

This is expensive. It is also the only model that survives an actual security audit.

Department isolation inside the client

Isolation does not stop at the client boundary. Inside a single client's deployment, every department — marketing, sales, support, recruiting, engineering — runs on its own sub-server. The support team's agents cannot read marketing's memory. The sales pipeline cannot see recruiting's candidate notes.

Cross-department exchange routes through Mai, the single concierge gateway. Mai validates every request, checks scope, and decides what gets released. There is no back channel, no shared bus, no "just join the tables." If sales needs a support transcript, the request goes through Mai, gets logged, and either resolves with the minimum data required or gets refused.

This is the same principle a well-run human company uses to manage confidential information. We built it into the infrastructure so it cannot be bypassed.

GDPR via Frankfurt

All EU client data is processed and stored in our Frankfurt facility. Full stop. Nothing routes through Singapore or Phuket for "load balancing." Nothing gets backed up to a US region for "redundancy."

This makes GDPR Article 28 (processor obligations), Article 32 (security of processing), and Article 44 (international transfers) tractable. Our DPA names Frankfurt as the processing location, and the architecture enforces it. Your legal team gets a one-page answer instead of a three-month audit.

Audit trail you can actually read

Every agent action, every cross-department request, every decision Mai makes is logged to an immutable, client-visible audit trail. Not "available on request." Visible in the client dashboard, in real time.

This matters for two reasons. First, when something goes wrong — a wrong email sent, a wrong report generated — you can trace the exact decision chain that produced it. Second, when a regulator or a board member asks "what is this AI actually doing with our data," you have an answer with timestamps.

SLA and self-healing

SVI Marketing runs at 99.9% uptime. HandOfHands runs at 99.95%. Both are backed by automatic failover to backup nodes within seconds — we keep six backup facilities (Bangkok, KL, Tokyo, Seoul, London, NY) on standby in addition to the three primary regions.

Recovery is run by AI agents, not by a human on a pager. When a node degrades, the system reroutes, spins up a fresh instance, replays state from the audit log, and notifies the client of what happened. The mean time to recovery is measured in seconds, not in how long it takes someone to wake up.

How to start

If you are evaluating AI infrastructure for a regulated business — finance, healthcare, legal, anything touching EU personal data — start with the architecture, not the demo. Read our security model and the underlying platform architecture. If you want the enterprise turnkey deployment where the isolation guarantees apply end-to-end, see how HandOfHands works. When you are ready for specifics on your data residency and SLA requirements, talk to us directly.

Talk to Mai

She knows the product cold — pricing, modules, deployment. She loops in the team when you are ready.

Open chat with Mai