Privacy Policy

Who we are

Roar AI is a platform for companies. It does two things: it gives your employees one key that reaches every major AI model, and it hosts the internal apps they build. This policy explains what we do with the information that passes through it.

The service is operated by Roar AI Pvt. Ltd., registered at 11A Milepost Avenue, Colombo 03, Sri Lanka.

We handle two different kinds of information, and our role differs for each. For the people who sign up, sign in and administer an account, we decide what is collected and why — that is described below. For everything a customer’s own employees and apps send through the platform — prompts, files, app databases, the visitors their apps serve — we act only on that customer’s instructions. We do not decide what their apps collect, and we do not use it for our own purposes. In the language of data protection law we are the controller of the first and the processor of the second.

What this policy covers

It covers:

this website, roar-ai.com, including the documentation
the console, where administrators and employees manage models, keys, spend and apps
the gateway API that serves model requests
the hosting service, and the apps and databases it runs

It does not cover the websites and apps that our customers build — those belong to the customer, who is responsible for their own privacy notice. It also does not cover what a model provider does once a request reaches them; that is set out in Prompts and model providers below.

What we collect

Signing in

We hold your name, your email address and whether you are an administrator or an employee. Accounts are created by invitation, or by a request an administrator approves — there is no anonymous sign-up that reaches a live account.

There are two ways in: a link emailed to you, valid for fifteen minutes and usable once, or a password you set yourself. A password must be at least twelve characters and your email address must be verified before it works. We never store a password itself — only a hash of it, which cannot be turned back into the password. Resetting one goes through the emailed link rather than a separate reset flow. A signed-in session records the IP address and browser user-agent it was created from, so that you can see and end your other sessions, and expires after thirty days.

Your company’s account

The company name, a contact, the country it operates from, its billing currency, spend limits and budgets, its credit balance and its invoices. The country is asked at onboarding and is used to place infrastructure and set the default currency.

API keys

A key is shown to you once, at creation. We store only a one-way hash of it and a short display prefix such as roar_live_a1b2, so the key itself cannot be recovered from our database — not by us, and not by anyone who obtains a copy of it. Alongside it we keep the key’s name, what it is allowed to do, its spend cap and when it was last used.

A record of each API call

Every request through the gateway writes one usage record. It holds the model requested, the endpoint and hostname called, the number of tokens in and out, how long it took, the HTTP status, what it cost and what it was billed, whether it was answered from cache, which routing policy applied, and — on a failure — an error code and a short message with secrets stripped out. Where a trusted network edge tells us, it also holds the two-letter country the call came from, which is used to decide where to serve traffic from and never for billing.

This record does not contain the text of the request or the answer. That is a separate, optional store, described next.

Prompt and response content

So that your team can look at their own call history and debug it, the platform can store the request and the answer for each call. This is the most sensitive thing on the platform, and it is treated that way:

it is a per-company setting, on by default, and an administrator can switch it off — with it off, nothing is written at all. The text passes through to the model and no copy is kept, so afterwards there is nothing for anyone to open: not your administrators, not our engineers, and nothing a court order or a stolen database could produce. The trade is yours to make, because switching it off also removes your own team’s ability to look back at what was sent;
it is encrypted before it is written, with AES-256-GCM, so the database never holds a readable prompt;
it expires automatically — after thirty days by default. An administrator can choose seven days, or to keep it until they delete it, and a scheduled job deletes what has expired. A shorter period, or switching it off, deletes what is already stored beyond it at once;
a body larger than 64 KB is replaced with a marker rather than stored.

Apps you host with us

When you deploy an app we hold what is needed to build and run it: the repository it comes from and the permission you granted to read it, the build settings and build logs, its domains, and its environment variables and connection strings. Environment variables and credentials are encrypted at rest and are never written to our logs.

Each app gets its own database on our servers in your region. Its contents belong to you. We do not read them, and we do not use them for anything other than running, backing up and restoring your app at your request.

Traffic to your hosted apps

So that you can tell why an app is slow or broken, we keep one row per request it served: the time, the method, the path, the status code, how long it took, how many bytes went back, which hostname was used and the request id our edge assigned.

We deliberately do not collect the visitor’s IP address, their browser user-agent, or the page they came from. Not hashed, not shortened — those fields do not exist in our database, so they never leave the machine that served the request. This is a stricter line than most hosting platforms draw, and it is drawn on purpose: our customer is a company whose apps serve other people, and storing those people’s addresses would make us a processor of their personal data for a field nothing in the product displays. The path does keep its query string, because a path that cannot tell two requests apart is not worth keeping; it is length-limited when it arrives. Alongside it we keep counters — requests, errors, response times — in five-minute buckets.

Administrative actions

Changes made through the console and the admin API are recorded: who acted, what they did, the result, and a summary of the request with secrets excluded. This is what lets us answer “who changed this” after the fact.

Getting in touch

If you use the request-access form on this site we collect your name, email address, company, phone number and what you told us you want to build, and pass it to the people who will reply to you. If you ask us to email you a link to set up on your computer, we keep your email address to send that link and, if you have not signed up two days later, one reminder. If you email or message support, we keep that correspondence.

Why we use it

To run the service. Route a request to a model, build and serve an app, keep a database available.
To meter and bill it. Usage records are what an invoice is made of, which is why they are kept longer than anything else.
To show you your own account — spend, budgets, which key is being used, which app is failing.
To keep it secure and available — detect abuse, enforce spend caps, investigate an incident, restore from backup.
To support you when you ask us something, and to reply to a sales enquiry you sent us.
To comply with the law, including keeping financial records for as long as we are required to.

We do not sell personal information. We do not train models on your prompts, your app data or your files, and we do not share them with anyone except as set out below.

What allows us to do any of this. Sri Lanka’s Personal Data Protection Act, No. 9 of 2022, requires us to have a lawful reason for holding your information. Ours are two: performance of a contract, because we cannot run your account without the details you gave us to open it, and our legitimate interests in keeping the platform secure, billing correctly and understanding how it is used. We do not rely on consent to run the service, which is why there is nothing here to withdraw and keep your account working.

Where it is stored

Where your data lives is a setting, not a promise in a document. Roar AI runs its own servers in the markets it serves — Sri Lanka, India and Singapore today — alongside a central control plane held with a cloud infrastructure provider.

Each company chooses one of three levels:

Flexible — the default. Any healthy route, wherever it is.
In-region processing — the gateway and the privacy guardrails must run inside your own country. Once a request has been screened there, it may go on to a model provider abroad.
In-region only — the model must be in your country too. The router refuses the request rather than sending it across a border, which is the point: it fails instead of quietly falling back.

Given that setting, the rest follows a single rule — data lives where the request was served.

Accounts, companies, keys, budgets and usage records are held centrally, so there is one login and one bill.
Your apps and their databases run on our servers in your region, one database per app.
Prompt and response content, where it is stored at all, is stored encrypted and centrally. For a company pinned to a region it is never stored, whatever the setting says, because storing it centrally would take it out of the country.

If you need a market we do not yet operate in, ask us before you rely on it rather than after — write to us at cloud@roar-ai.com and we will tell you what we can place where. A residency arrangement stricter than the settings above is agreed in writing rather than switched on from the console.

How long we keep it

Prompt and response content — thirty days by default, then deleted automatically. Each company chooses: seven days, thirty, until they delete it, or not stored at all.
Traffic logs for your hosted apps (each request’s path and status) — thirty days. The counters behind the charts are kept while the app exists. They hold totals, never a record of an individual visitor. Deleting an app deletes its traffic logs and counters with it.
The administrative audit log — kept as the security record of changes to an account, including after the account closes.
Usage records — seven years, or longer only where the law requires it. They are the evidence behind every invoice and the history behind every chart, and are deleted automatically once past that window.
Account and company records — for as long as the account is open.
App data and app databases — until you delete the app. Deleting it removes the database with it.
Backups — the last two days on the machine itself, and an encrypted copy held off it for ninety days, which is the one a restore reads. Delete an app and its data is gone from our backups within ninety days. See Security.
Invoices and financial records — ten years, as the Companies Act requires.

When an account closes we delete or anonymise what we no longer need. We keep what the law requires and the audit log of changes made to the account.

We use a small number of suppliers to run the platform. Each gets only what its job needs, and none of them is permitted to use it for their own purposes. By category:

Model providers — receive the content of a request when it is served by an external model. See the next section.
Cloud infrastructure and object storage providers — host the central control plane and hold encrypted backups.
Source-code hosting and container registries — where your app’s code is read from and its built image is kept.
Network and edge providers — carry traffic to your apps and terminate TLS.
Email delivery — sends sign-in links, invitations and account notices.
Payment processing — takes payment. Card details go to the processor, not to us; we never see or store a card number.
Advertising and analytics — on this marketing website only. See Cookies.

We may also disclose information where the law requires it, or to establish or defend a legal claim. If the business is ever sold or reorganised, account data may transfer with it; you would be told before that changed anything about this policy.

We name suppliers by the job they do rather than one by one. If you are reviewing us as a vendor and need the specific list, ask and we will give it to you directly.

Prompts and model providers

When one of your employees calls a model, the text of that call has to reach whoever runs the model. Some models run on our own hardware; most are run by the companies that built them. Which one served a given request is a decision the platform makes on your behalf, using the routing policy your company has set.

Two controls sit in front of that. A company can require that requests only go to private, self-hosted models, in which case nothing leaves our infrastructure. Or it can leave external models available and turn on guardrails: before a request leaves for an external provider, the platform scans it for personal data and credentials — email addresses, card numbers, national ID numbers, API keys, private keys, plus any pattern you add — and then redacts what it found, blocks the request, or reroutes it to a private model. Which of those happens is your setting.

Once a request reaches an external provider, what that provider does with it is governed by their terms, not ours. If that matters to you, the private-only and in-region settings above are the controls that make it a question you do not have to ask.

Claude and other AI assistants

You can connect an AI assistant such as Claude to your account through our MCP connector. Connecting takes a sign-in and your approval of what the assistant may do; the assistant never sees your password.

What we receive is only the actions the assistant asks us to perform and the details each one needs — an app’s id, the name of an environment variable, a query you asked it to run. We do not receive your conversation with the assistant, its chat history, or files you share with it.

What we keep is the connection itself: a registration for the assistant and the tokens that let it act for you. An access token expires within an hour and is renewed with a refresh token, which stops working the moment it is used and is replaced by a new one. Changes made through an assistant are recorded in the audit trail in the same way as changes made in the console, and kept for the period set out under “How long we keep it”.

What the assistant receives is what each action returns — a list of your apps, a log excerpt, the rows a query produced. That goes to the assistant you connected, and from then on is governed by that assistant provider’s terms, not ours. To stop an assistant acting for you, remove the connector in the assistant; any access token it already holds expires within the hour.

Cookies and tracking

The console’s sign-in cookie keeps you signed in. It is scoped to the console’s own hostname, is not shared with this website, and there is no way to use the product without it.

This website carries an advertising tracker and our own product analytics, on roar-ai.com including these documentation pages. Between them they record which pages are opened, how people move between them, where on a page people tap, a replay of the visit, and whether a form was submitted — not what you typed into it. Both set cookies to recognise a returning browser, and both hold their data outside Sri Lanka. What you type is never recorded: form fields are masked before anything is sent, and so is the line that greets you by name. Your name, email and message reach us directly and are not passed to either. Analytics events are sent through a subdomain of ours, so blocking them means blocking that subdomain rather than a name on a tracker list.

Inside the console we measure product usage, and there it knows who you are. Your name, email and company name are sent to our analytics provider and held outside Sri Lanka, so that we can see which accounts use the product and support them properly — a deliberate choice, stated here rather than left to be discovered. It runs for customer accounts only: our own operators are never measured, and neither is an operator looking at your account through your console, so our activity is never counted as yours. It records which screens are opened, with resource identifiers removed from the address first, and events we write on purpose. It does not record your screen, your keystrokes, your data, or the text of anything on the page — automatic click capture and session replay are both switched off in our code, because the contents of a signed-in console are your information rather than ours. It does not run against your hosted apps.

The sign-up page is measured the same way, before you have an account: that it was opened and whether the form was sent, under the same limits. When you sign up, your earlier visits to this website are joined to your new account, so we can tell which pages lead people to sign up. What you type into the form is not sent to our analytics provider.

Our servers also tell it about milestones in your account — that you signed up, created a key, made your first call, deployed an app, paid, or are running low on credit — with your name, email and company, including before you first open the console. We use them to send you emails that help you get started and keep your account running. Every one of those emails has an unsubscribe link. Messages about sign-in, security and your bill are not marketing and are always sent. We keep a record of which of our emails we sent you — the kind and subject line, never the body — and whether your address bounced or marked one as spam, for 12 months. We do not track whether you open them or click their links.

Some of those milestones are also shared with the advertising tracker, along with some of your account and browser details, so that we can tell which ads lead to accounts people use.

The one exception is an error. When something breaks in the console we are sent its type, its message and the trace through our own code — enough to find the fault in the session it happened in. That is our code and our wording, not the contents of your screen.

There is no cookie-consent banner on this site. We considered one and decided it is not required for the markets we advertise in. If that changes, this page changes with it.

If you are reviewing us as a vendor and need each provider named, ask and we will tell you directly.

How we protect it

We describe what we do, not what we have been certified to do. We hold no security certification and make no compliance claim in this document.

Secrets are encrypted at rest with AES-256-GCM — your environment variables, your app database credentials, our provider credentials, and stored prompt content. The encryption is authenticated, so tampering is detected rather than decrypted.
API keys are never stored. What is stored is a one-way hash, computed with a secret the database itself does not contain, so a key cannot be read back out of it.
The server decides what you may see, never the browser. Every request is scoped to the company it came from before any data is read, and a request for something belonging to another company is answered as though it does not exist.
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.
Backups are encrypted so that the machine making them cannot read them. The key that opens a backup is held offline by an operator and exists on no server, which means a stolen server or a stolen backup bucket yields ciphertext. Restoring is a deliberate two-person act, not a button.
Prompt logs are not backed up at all. They are a short-lived debugging trail, not a system of record, and leaving them out of backups removes any question of prompt content outliving its retention window or leaving its region.

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.

Your choices and your rights

Some of this you can do yourself, today, from the console:

turn prompt and response storage off for your whole company, so nothing is written;
revoke or delete an API key, and see when each one was last used;
delete an app, which deletes its database with it;
end your other signed-in sessions;
as an administrator, remove an employee from your company;
as the owner, delete your company’s account, which removes its apps, keys, logins and settings and keeps only the billing records the law requires.

Beyond that you can ask us for a copy of the personal information we hold about you, ask us to correct it, ask us to delete it, or object to a particular use. Write to us at the address in Contact and we will reply within thirty days.

If you are an employee of a company that uses Roar AI, your account belongs to that company. Ask your administrator first — they can act on most of the above immediately. Where we hold the data only on your employer’s behalf, we will refer your request to them rather than act on it ourselves.

These rights come from Sri Lanka’s Personal Data Protection Act, No. 9 of 2022. If you are not satisfied with how we have handled a request, you can complain to Sri Lanka’s Data Protection Authority. We have appointed a representative for data protection matters; write to them at legal@roar.global.

Children

Roar AI is sold to companies and is built for their employees. It is not directed at children and we do not knowingly collect information from anyone under 18. If you believe a child’s information has reached us, tell us and we will delete it.

Changes to this policy

We will update this page when what we do changes. The date at the top is the date of the current version. If a change materially affects how we handle your information, we will tell account administrators by email before it takes effect rather than relying on you to notice.

Contact

Questions about this policy, or a request about your own data, go to cloud@roar-ai.com, or by post to 11A Milepost Avenue, Colombo 03, Sri Lanka.

If you are not yet a customer and want to talk to someone, get in touch — we are in Colombo.