Yours. Not a shared room.

1 · The shared-tenant problem we built away from

The default architecture for AI products in 2026 looks like this: one model, one database, one logging pipeline, every customer’s prompts and replies and uploaded files moving through it. It is cheap to run. It is also a category of risk you can’t audit out.

• History bleed. A bug in caching, session handling, or a Redis index can show one customer’s chat titles — or replies — to another. The whole shared-tenant industry has lived through public versions of this.
• Prompt-injection across customers. When the same agent answers Alice and Bob using the same long-running memory layer, a poisoned input in Alice’s conversation can change how the agent treats Bob. "Memory" sounds friendly; in a multi-tenant agent, it is also an attack surface.
• System-prompt and file extraction. A custom assistant configured with private instructions and reference documents can be made to reveal them with a few well-crafted lines. This is broadly demonstrated, in public, across the agent-builder market.
• Support staff with access to logs. Support inevitably needs to see something — and in a shared-tenant model "something" tends to be the whole table. Logs that include prompts are logs that include your work.
• Model-provider retention. Most shared products send your prompts to a model API that quietly retains them for 30 days "for abuse monitoring." That window is invisible to the end user and longer than most people’s threat models assume.

We do not have a clever fix for any of these inside a shared-tenant architecture. We chose not to build one.

2 · A server of your own

Every Ermes account gets a dedicated server we provision in your name. No multi-tenancy, no shared agent context, no sneaky background processes from another customer’s setup. If your server has a bad day, only your agent is affected.

When somebody asks "how do you protect customer A’s data from customer B?" the Ermes answer is structural, not procedural: there is no customer B on your server. There is no shared queue, no shared cache, no shared memory store, no shared logging tail. We don’t have to promise we won’t make the kind of mistake we made architecturally impossible.

3 · Encryption

Disks on your server are encrypted at rest. Connections between you, your messengers, and your agent are encrypted in transit (TLS). Backups, when present, are encrypted with keys we don’t reuse across customers.

4 · Threats this design refuses

A short, honest list of attacks we will not have to apologize for. Not because we’re clever — because the architecture doesn’t give them a foothold.

• Cross-customer chat history leak. No shared database holds two customers’ conversations.
• Prompt injection from another tenant’s session. No other tenant shares your agent’s memory.
• Mass system-prompt extraction. Your agent’s configuration lives on your server; an attacker would have to compromise your machine specifically.
• Support tooling that bulk-queries customer logs. No shared logs to bulk-query. We log to your machine.
• Model-provider retention of your prompts. Zero-retention agreements where supported; BYOK if you want stricter control.
• Vendor employee curiosity. No standing access. Time-boxed, read-only, audit-logged, with your consent.

5 · Permissions that ask

Anything that touches the world — sending a message, paying, scheduling, deleting — stages itself and asks you to approve. You can revoke any permission, any tool, any time. The point: irreversible actions cost a tap, not a regret.

6 · Who can see what

By default, Ermes staff have no access to your server. When you ask for support, you can grant temporary, read-only access; we close that access automatically after 24 hours. We log every staff session and you can review it in your account.

7 · Updates & patching

Your server is updated automatically with security patches. Major upgrades are announced and can be deferred for short windows so they don’t land mid-conversation. Critical zero-days ship out-of-band; we tell you what changed and why.

8 · Data boundaries

Here’s the exhaustive list of what leaves your server. If it’s not on this list, it’s not leaving.

• On your server: your agent’s memory, your conversations, the routines it runs, technical logs.
• In our control plane: your account email, subscription state, server status — the basics needed to operate the platform. See Privacy for the full list.
• With model providers: only the prompt and tool inputs needed to answer a given turn. Zero-retention agreements where the provider supports them. See Sub-processors.

9 · Bring your own keys

You can route model traffic through your own API keys (Anthropic, OpenAI, Mistral, Gemini). When you do, your zero-retention agreement carries over and we keep no copy of the prompts.

10 · Responsible disclosure

If you find a security issue, please write to [email protected]. Include enough detail to reproduce it.

• We acknowledge new reports within 1 business day.
• We’ll keep you updated as we triage and fix.
• We won’t pursue legal action against good-faith research that respects user privacy and avoids data destruction.
• If you’d like public credit once a fix ships, tell us — we’ll list reporters on this page.

11 · Incident response

If we have a confirmed security incident that touched your account, we’ll email you within 72 hours of confirmation with what happened, what we know, what we did, and what you should do.

12 · Questions to ask any AI provider

If you’re evaluating us against anything else, these are the questions the answers to should not feel rehearsed:

• Where physically does my conversation live? Is it on a server only my account uses?
• Who else’s data is on the same server, database, or memory store as mine?
• If a researcher extracts another customer’s prompts from your platform tomorrow, what is the disclosure timeline?
• What’s the maximum number of customers a support engineer can read with one query?
• Does the model provider retain my prompts at all? For how long? Is that retention visible to me?
• If I cancel today, when is my data deleted and how do you prove it?

Our answers, in order: a dedicated VM in your region; nobody; same-day acknowledgement and 72-hour incident email; one (yours, with your consent); zero-retention or BYOK; 7 days, with a deletion attestation in your account.

13 · Compliance & certifications

We’re a small team building in Silicon Valley. GDPR rights apply to every user. We do not currently hold a SOC 2 or ISO 27001 certification; if your organization needs one, please write to us — we’ll let you know our roadmap.