How we protect your data

What this page is

A description of how the platform is built to protect your data, written for someone deciding whether to trust it with theirs. It is a companion to the Privacy Policy, which covers what we collect and why, and the Terms, which cover the commercial relationship.

It describes what we do, not what a badge says we do. Where a number appears here, it was measured.

Getting into an account

• Two ways in, and neither leaves a password we can read. Sign in with a link emailed to you — valid for fifteen minutes, usable once, and rate-limited — or with a password you set yourself. A password must be at least twelve characters and your email address must be verified before it works. We store a hash of it, never the password, so it cannot be read back out of our database. Resetting one goes through the emailed link rather than a separate reset flow.
• Accounts arrive by invitation, or by a request an administrator approves. There is no anonymous sign-up that reaches a live account.
• A session records the address and browser it was created from, so you can see your other sessions and end them. Sessions expire after thirty days.
• API keys are never stored. What is stored is a one-way hash computed with a secret the database itself does not contain, alongside a short display prefix. A key cannot be read back out of our database — not by us, and not by anyone who obtains a copy of it.
• A key is scoped, capped and expirable. One key can be allowed to call models and nothing else, so a key living in an application cannot manage your account. Each carries its own spend limit, an optional expiry date, and a last-used time; the tightest limit of key, project and company applies. A leaked key is therefore bounded before you notice it — it can spend only what that key was allowed to spend — and revoking it takes effect at once.

Keeping companies apart

The platform is multi-tenant, so the question that matters is what stops one company reaching another’s data. The answer is that the browser is never asked.

• The server decides what you may see. Every request is scoped to the company it came from before any data is read; the scope is taken from your session, never from anything the request supplies.
• A request for another company’s resource is answered as though it does not exist — not as “forbidden”, which would confirm that it does.
• Your apps and their databases are separate from each other. An app database is reachable from its own app, not from the public internet.

Stopping data leaving by mistake

The risk with an AI gateway is not usually the platform. It is an employee pasting something into a prompt that should never have left the company — a customer record, a card number, an internal key.

The gateway can read a request before it goes anywhere and act on what it finds. Detection covers personal data and credentials, and you can add patterns of your own. It is deliberately conservative rather than eager: a card number has to pass a checksum before it counts, because a guardrail that cries wolf is one somebody turns off.

Each company chooses what happens on a match:

• Redact — the sensitive span is removed and the rest of the request goes on.
• Block — the request is refused and never leaves.
• Reroute — the request is sent to a model we run ourselves instead of an external one, so it stays inside the boundary rather than being stopped.

The outcome is recorded against the request, so you can see what was caught and how often — without the matched text being kept.

Encryption

Everything is encrypted at rest, at every layer, and the sensitive parts are encrypted again inside it. Reading one layer is not enough to read what matters.

• Your databases and your app data are encrypted at rest, in all three regions — and so is the platform database holding accounts, keys and usage records.
• Secrets are encrypted again, on top of that, with AES-256-GCM: your environment variables, your app database credentials, our provider credentials, and stored prompt content. Somebody holding the database still holds ciphertext for every one of them. The encryption is authenticated, so tampering is detected rather than quietly decrypted.
• Backups are encrypted to a key we do not hold, so the machine that makes one cannot read it back. See Backups and recovery.
• Traffic is encrypted in transit, and our own servers talk to each other over a private network rather than the public internet. The machines that hold customer data accept no administrative connection from the public internet at all.
• Whether prompts are stored at all is your decision, not ours. It is a per-company setting. With it on, content is encrypted before it is written and deleted automatically after a short retention window — seven days by default. With it off, nothing is written: the text passes through to the model and no copy is kept, so there is nothing for anyone to open afterwards — not your administrators, not our engineers, and nothing a court order or a stolen database could produce. The trade is yours to make: switching it off also removes your own team’s ability to look back at what was sent.

Backups and recovery

• Databases are dumped twice a day. Each dump is verified, encrypted and shipped off the machine that made it. The off-site copy is the one a restore reads; the machine itself keeps only the last two days, because a local copy is a convenience for an operator rather than the thing protecting you. Off-site copies are deleted after ninety days, so when you delete an app, its data leaves our backups within that window rather than sitting there indefinitely.
• A backup is encrypted so that the machine making it cannot read it. The key that opens one is held separately and never on a server, so a stolen machine or a stolen backup store yields ciphertext. Restoring takes two people — one to run it, a second to confirm out of band that it was asked for. It is never a button.
• Prompt logs are not backed up at all. They are a short-lived debugging trail rather than a system of record, and leaving them out of backups removes any question of prompt content outliving its retention window or leaving its region.
• Restores are practised, not assumed. “We take backups” and “we can restore” are different claims; we rehearse the second one and record what it measured.

The number to plan against: up to twelve hours. That is the worst-case amount of recent work a restore could cost you, and it follows directly from dumps taken twice a day. It is the honest figure rather than the flattering one.

Where your data runs

You choose the region. Your app, its database and its backups stay in the region you picked. Colombo, Singapore and Bangalore are live today.

Model calls are the exception worth understanding. A call to a frontier model reaches the company that built it, as it would from any other tool. If a call must not leave, guardrails can block it or send it to a model we host ourselves. In-region processing and storage can be configured for your account on request — see the Privacy Policy, and write to us at cloud@roar-ai.com.

During a declared incident, data may be recovered in another region so that the service can be restored. We do not continuously replicate customer data across borders outside of that.

Availability, and what we will and will not promise

We publish an uptime figure when we can stand behind it, and not before. An availability percentage is a claim about a measured history, and we would rather show you what has been exercised.

• the gateway steers traffic to the region nearest your users, across three markets, and failover between markets has been rehearsed;
• an app that loses its machine is recovered by redeploying it rather than by rebuilding that machine, and moving an app between regions is a routine operation rather than a disaster procedure;
• every backup is encrypted, held off the machine that made it, and restore-rehearsed.

Support runs during business hours, from the engineers who run the platform rather than a tier-one queue. The hours and response times that apply to your account are set out in your agreement.

Availability commitments and service credits are agreed in your contract, against the workload you actually run, rather than published as one number for everybody. Talk to us about what you need.

Who can touch what, on our side

• Administrative actions are recorded — who acted, what they did and the result — for changes made through the console and the admin API.
• Operator access is scoped. Internal tools are reached with credentials limited to the areas they are for, rather than one key that opens everything.
• Our servers take keys, not passwords, and the list is enforced rather than trusted. Every machine is configured from code with the exact set of keys allowed on it, and any key that is not on that list is removed rather than left in place. Each box then re-checks its own configuration continuously and reports drift, so a change made by hand shows up instead of persisting quietly.
• An operator can view your console to support you, and that view is time-limited and marked as such on screen while it is active.

Every server checks itself, continuously

A security baseline that is applied once and never looked at again is a baseline that drifts. Ours is applied from code, and then each machine re-audits itself against forty-five checks and reports the result — so a change made by hand, a certificate that stopped renewing or a service that came back up wrong shows up rather than waiting to be found.

Among the things every box proves about itself, on a loop:

• password and root logins over SSH are disabled, and only declared keys are present;
• the firewall is up, and nothing is listening publicly that should not be;
• the database is not reachable from the internet, and its connections are encrypted;
• certificates are renewing, security updates are applying, and the clock is in step.

The checks have been deliberately broken to confirm they go red. A monitor nobody has falsified is a monitor that reports what it was written to report rather than what is true, and we would rather find that out ourselves than during an incident.

Limits that contain a mistake

Most incidents on a platform like this are not attacks. They are a loop that should have stopped, a key pasted where it should not have been, or a job that ran a thousand times instead of once. The controls are the same either way.

• Requests per minute, tokens per minute and simultaneous calls are all capped per account and per key, so a runaway process is throttled rather than allowed to spend.
• Spend limits sit on the key, the project and the company, and the tightest one wins. A budget is a hard stop, not a notification after the fact.
• Anything we send you is signed, so a webhook your systems act on can be checked as genuinely ours before it is trusted.

Reporting a vulnerability

If you have found something, we would rather hear it from you than from an incident. Write to cloud@roar-ai.com with enough detail to reproduce it. We will confirm receipt, keep you updated while we fix it, and credit you if you would like to be credited.

Please do not test against another customer’s account or data. If a proof needs more than your own account can show, tell us and we will arrange it.

No system is perfectly secure. If we become aware of a breach affecting your data we will tell you within seventy-two hours of becoming aware of it, and we will notify Sri Lanka’s Data Protection Authority in the same window where the breach is likely to put your rights at risk.