Data Use

1. How a request works

When an End User asks Stiro for something, the Stiro script in their browser reads the page they are on and sends it, with their request, to our servers over an encrypted connection. Our servers use AI models to decide the next step, and the script carries it out in Your App as that End User, until the request is done or it stops. Stiro is designed to wait for the End User to confirm anything that sends, spends or deletes.

The Customer (the business that installed Stiro) is the controller of this data and decides whether and where Stiro runs. We act as its processor under our Data Processing Addendum.

2. What Stiro handles during a request

Data	Why	Kept
The End User’s request	To know what to do	Only while the request runs, except a summary with entered values replaced by placeholders, kept in the run record (section 5)
The content of the page, including its address, visible text, and values in ordinary form fields	To find its way and check each step	Only while the request runs
Context from the End User’s current session in Your App, such as recent requests	To follow on from earlier requests	Only while the request runs
Audio, when the End User speaks a request instead of typing it	To turn it into text, which the End User then checks and sends	Only while it is transcribed. Not stored
Your App’s id for the signed-in End User, and its signature from your server, if you pass them	Per-user daily limits, and knowing the id is really that user’s	Only as a keyed hash on run records, never the id itself. The signature is checked and not stored
IP address	Rate limiting and abuse prevention	In memory only. Not stored in our database

Because Stiro reads the page, anything Your App shows the End User may be processed, including personal data such as names and email addresses. Only enable Stiro on pages where that is appropriate, and see section 8 for how to tell your End Users.

3. What never leaves the browser

• Sensitive fields. The values of password fields, and of fields recognisable as payment card, bank account, government ID or one-time code fields from their type, autocomplete value, name or label, are never sent. Stiro never types into these fields, even with a value from the request: it hands them to the End User. Marking such fields with standard attributes helps make sure they are recognised.
• Cookies and credentials. The script does not read cookies or send them to us, and never reads the End User’s password. Stiro never asks for one; a password typed into a request itself would reach us like any request text, so tell your users not to.

The script sets no cookies. It keeps recent requests and the progress of the current request in the browser’s local and session storage, so that suggestions and multi-page requests work. You can get the exact storage keys for your own storage notice by writing to privacy@stiro.ai.

4. AI models and training

Stiro uses third-party AI models to decide each step. We use them only on terms that prohibit training on what we send, and we use zero-data-retention service wherever the provider offers it, so the provider does not store prompts or answers.

Nobody trains AI models on your data. Not us, and not our providers. What Stiro learns about Your App is used only for your workspace.

5. What we store, and for how long

What	Contents	Kept
Run records	Outcome, timing, usage and cost, and a summary of the request with the values it picked out or entered replaced by placeholders (such as “invite {email} as {role}”). The full request only if the Customer asks us to keep it	While the workspace exists
App map	A map of Your App’s screens and controls, processed to remove identifiers and personal data before it is stored	While the workspace exists. You can delete screens from the dashboard
Server logs	Technical events and errors, designed to exclude requests and page content	A rolling buffer of about 100 MB per server; the oldest entries are overwritten
Backups	An encrypted copy of the database	35 days

We do not store the text End Users type (beyond the request summary, unless the Customer asks us to keep full requests), the content of your pages, or End Users’ identities. A request summary can still contain words that were not entered into a field, so do not ask your users to put secrets in requests.

Deletion. When you remove a site, its keys and app map are deleted from our live systems at once, and leave our backups within 35 days. To close a workspace or account and delete its data, email privacy@stiro.ai. We delete it within 30 days, and it leaves our backups within a further 35 days. We also delete a workspace’s data within 30 days after the Terms end.

6. What we never do

• Sell data, or use it for advertising.
• Use one customer’s data, or what Stiro learned about their app, for another customer.
• Train or fine-tune AI models on Customer Data, or let our providers do so.
• Look at the contents of your workspace, except when you ask us to help, when we must to keep the Service secure, or when the law requires it.

7. Your controls

• Where Stiro runs. Stiro works only on the domains you list, and you can switch it off for a site at any time from the dashboard, which also stops any request in progress.
• How much each user can do. Pass your signed-in user’s id and each user gets a daily limit you set (50 runs by default). We recommend signing the id on your server with your site secret, so nobody can make up users. You can require an id, or a signed id, on every page; pages without one don’t get Stiro.
• What it keeps. Delete learned screens from the dashboard, or ask us to delete a workspace.
• What it does. Stiro can only act with the End User’s own permissions in Your App, and is designed to wait for confirmation before anything that sends, spends or deletes.

8. Telling your End Users

As the controller, you are responsible for telling your End Users about Stiro in your own privacy notice and for having a lawful basis to use it. Wording you can adapt:

We use Stiro, an in-app assistant, to carry out requests you make in [product]. When you use it, the request and the content of the page you are on are processed by Stiro and its service providers to perform the request. Password, payment and ID fields are designed to stay in your browser. Stiro does not use your data to train AI models. Learn more at stiro.ai/data-use.

9. Service providers

We use these providers to run Stiro. Each is bound by a contract that requires it to protect the data and use it only to provide its service to us.

Provider	Service	Location
Amazon Web Services	Hosting, database and email delivery	United States
Cloudflare	Network security, content delivery, website hosting and encrypted backups	Global network; backups in North America
OpenRouter	AI model access and speech transcription, only through providers that keep no data	United States
TypeSafe	AI model provider	United States
Google (Gmail)	Email we receive at stiro.ai addresses	United States

Dodo Payments, our reseller and merchant of record, handles customer billing as an independent controller under its own privacy policy. It never receives End User data and is not a sub-processor.

Changes. We update this list before a new provider starts handling Customer Data. Customers who want advance notice can write to privacy@stiro.ai, and we will email them at least 14 days before a change. The Data Processing Addendum explains how to object.

10. Security

• Encryption in transit everywhere, and at rest for our database and backups.
• Each workspace’s data isolated from every other’s.
• Passwords stored only as one-way hashes, and site secrets encrypted.
• Daily encrypted backups, kept separately and protected against deletion.
• Production access limited to authorised personnel, with multi-factor authentication.

A security overview is available to customers on request. To report a vulnerability or a concern, write to privacy@stiro.ai.