Security

1. How Stiro works

You add one script to your app. When a user asks Stiro for something, the script reads the page they are on and sends it, with their request, to our servers over an encrypted connection. Our servers decide the next step, and the script carries it out in the user’s browser, as that user. Nothing runs on your servers, and our servers never connect to your app, its backend or its database.

What is sent, stored and for how long is set out on our Data Use page. This page covers how we protect it.

2. In your app

It acts as your user, nothing more. Stiro clicks and types in the page the way the user would, so your app’s own permissions, validation and confirmations apply to it exactly as they apply to them. It has no keys to your app and cannot reach anything the user can’t.

It doesn’t touch credentials. The script never reads cookies and never sends them to us: its calls to Stiro are made without credentials. The values of password fields, and of fields it recognises as payment card, bank account, government ID or one-time code fields (from their type, autocomplete value, name or label), are replaced before anything leaves the browser, and Stiro never types into them: it hands those fields to the user.

The user presses what can’t be undone. Before each click, Stiro judges whether it would send, spend, delete or otherwise do something that can’t be taken back. Those it never presses itself: it points the user at the control and waits for them.

It keeps out of your page. Stiro draws its interface inside its own closed shadow root, so your styles and scripts don’t reach it and its styles don’t leak into your page. Outside it, it adds its launcher button and its own script tags, and, while it works, may briefly add a style rule to show a control that appears only on hover, or open a link in the same tab. It undoes those changes when it’s done. It doesn’t patch your page’s functions or watch its network traffic.

What it keeps in the browser. A few stiro: keys in local and session storage, for recent requests and for carrying a request across pages. It sets no cookies and reads no other storage.

3. Content Security Policy

If your app sets a Content Security Policy, allow Stiro with:

Directive	Add
script-src	https://app.stiro.ai
connect-src	https://app.stiro.ai wss://app.stiro.ai
style-src	'unsafe-inline' (Stiro’s styles are injected at run time)
img-src	data:, only if you use a custom cursor image

Stiro never needs 'unsafe-eval', inline scripts or workers, and loads no fonts or assets from other hosts. Speaking a request asks for the microphone through the browser’s own permission prompt. The script is served from one address and updated in place, so it carries no integrity hash.

4. Keys and controls

• Keys tied to your domains. Your site key is public by design, like any embed key, and works only on the domains you list: scheme, host and port must match, and *.example.com matches subdomains only. Requests from anywhere else are refused.
• Signed users. Pass your signed-in user’s id, signed on your server with your site secret (HMAC-SHA256), and nobody can pose as another user or make up new ones to get around limits. We check signatures in constant time and store only a keyed hash of the id. Your site secret is encrypted at rest and shown once; making a new one revokes the old.
• Limits. Each user gets a daily limit you set, and every plan stops at its limit. Requests are also rate limited per address, per key and per user.
• Off switch. Turn a site off in the dashboard and Stiro stops on it at once, including any request in progress.
• Dashboard sign-in. There are no Stiro passwords to steal: you sign in with a one-time email link that expires in 15 minutes, or with Google or GitHub, where your own multi-factor authentication applies.

5. Data and AI models

• AI models. We reach AI models only on terms that forbid training on what we send. Requests through OpenRouter go only to providers that don’t train on them.
• Minimal storage. We don’t store the content of your pages, and keep requests only as a summary with the values replaced by placeholders, unless you ask us to keep full requests.
• Logs. Server logs are built to leave out request text, page content and tokens, and are kept in a small rolling buffer that overwrites itself.

The full list of providers, and what each handles, is on our Data Use page.

6. Infrastructure

• Hosting. Our servers and database run on Amazon Web Services in the United States. The database is not reachable from the internet, and its storage is encrypted.
• Network. All traffic comes through Cloudflare, which enforces HTTPS with TLS 1.2 or later. Our servers aren’t directly reachable from the internet, and every connection between our systems is encrypted.
• Workspace isolation. Each workspace’s data is separated by row-level security in the database itself, so a query can only see the workspace it runs for, even if application code were wrong.

7. Backups and recovery

• Point-in-time recovery for the database over the last 7 days.
• Nightly backups, encrypted with AES-256 and stored with a separate provider. Each is locked against deletion for 30 days, and deleted after 35.
• A failed backup alerts us straight away.

8. Access

• Strong sign-in. Production access is limited to authorised personnel and requires multi-factor authentication.
• Least privilege. Every account and service gets only the access it needs, and none of our automated systems can delete the database or its backups.
• Secrets. Production secrets are never kept in source code.

9. Building and running

• Every change passes automated tests, type checks and strict static analysis before a release is built.
• Releases are built automatically from locked dependency versions.
• We monitor uptime, server health and errors around the clock, and are alerted as soon as something fails. Our internal tools sit behind single sign-on.

10. Compliance

We are an early company, and say so plainly: we don’t hold SOC 2 or ISO 27001 certification yet. What we offer today:

• A Data Processing Addendum under GDPR Article 28, with the EU Standard Contractual Clauses and the UK Addendum.
• Written answers to a reasonable security questionnaire. Write to [email protected].
• Notice within 72 hours of confirming a personal data breach that affects your data.

11. Reporting a vulnerability

If you think you’ve found a security problem in Stiro, write to [email protected] with the steps to reproduce it. We’ll reply within two business days, keep you posted while we fix it, and credit you if you’d like. Please test only against your own account and site, and don’t access other people’s data or disrupt the service.