Security

Guarantees the shape of the system makes true.

An agent can run for hours and send sensitive prompts, tool results, and internal context through its model API. The boundary around that inference traffic has to be structural, not a promise in a policy document. This page explains what Sideren guarantees today, in plain terms.

The boundary[01/03]

Separation you can't misconfigure.

The strongest controls are the ones nobody has to remember to apply. Tenancy comes from the credential rather than the payload, and isolation is baked into the storage key itself — so there is no filter to forget and no flag to set wrong.

The drawing on the right is the whole mechanism: three requests arrive, the one asserting a tenant its key didn't earn dies at the gate, and the two that pass land in one physical pool as salted cells that can never address each other.

ONE REQUEST'S TENANCYMECHANISM
Status: live
SEC-01

Your key decides your tenancy

Which tenant a request belongs to is derived from the credential that authenticated it — never from anything in the request body. A payload that tries to assert a different tenant is rejected at the door, not reconciled later.

SEC-02

Caches can't cross tenants

Every cache and storage key is salted with an isolation domain derived one-way from your authenticated tenant. Two tenants cannot address the same entry — separation is a property of the key, not a lookup that has to remember to filter.

SEC-03

Provider credentials are never yours to hold

You hold one Sideren key. Upstream provider credentials live with the gateway, rotate with the gateway, and are never issued to you, printed in a response, or exposed to your agents.

SEC-04

Keys are named, and revoked instantly

Issue a key per agent, per machine, per environment — each one named, so months later you can tell them apart. Revoke from the dashboard and it stops authenticating; nothing else you run has to change.

Two tenants · one seam
Your data[02/03]

Kept for a bounded time. Never sold.

What we keep, we keep for a bounded time and for reasons we can name — running the service, finding failures, stopping abuse, and improving the system. The full detail, including your rights over it, is in the privacy policy.

Status: live
DAT-01

Used to run and improve the system

The content of your requests and responses is used to run the service. From 2026-10-01 it may also be used to improve the system, including training the models that decide how requests are routed. It is never sold.

DAT-02

A bounded window, then gone

Request metadata is kept while your account is active. The content of requests and responses is kept for a bounded period — up to one year — for reliability, debugging, abuse prevention and improving the system, then deleted. Account data lives as long as your account does.

DAT-03

We never see your card

Payment details are collected and held by our merchant of record. They do not pass through our systems and we do not store them.

DAT-04

A short list of processors

Payments, authentication and database, hosting, and the cloud compute we use to train our routing models. Your data goes nowhere else, except where the law requires it, and it is never sold.

Reporting[03/03]

Found something? Tell us first.

If you believe you have found a vulnerability, email security@sideren.io with enough detail to reproduce it. We will confirm receipt, keep you updated while we work, and credit you when it is fixed if you'd like us to. Please give us a chance to ship a fix before disclosing publicly.

Put the boundary to work

One key, one boundary, and inference built for long-running agent work.

Running this inside your own network instead? Sideren Enterprise is the private deployment, where the boundary is your perimeter and nothing egresses at all.

Put your agent on inference built for the work

Your agent stays the same.
Its inference gets better.

$export ANTHROPIC_BASE_URL=https://api.sideren.io

Start free · no card · Paid plans from $5/mo