Security
How Runner protects customer data, what we enforce in production today, and how to reach us if you find a problem. Everything on this page is either verifiable from outside or stated as not yet done.
What is in place today
Tenant isolation is enforced by the database, not by application code
Every company's data is separated by Postgres row-level security. Authorization is a property of the data itself rather than a filter the application has to remember to apply, so a missed check in a query cannot expose another company's rows. As of the date below this covers 976 row-level-security-protected tables through 2,127 policy functions, and a schema verification runs against production on every migration to confirm none of it has drifted.
Access is invite-only and passwordless
There is no public self-service signup. An account has to be created before it can sign in, and sign-in is a one-time emailed link rather than a password — so there is no password to reuse, leak, or phish, and no credential-stuffing surface.
Encrypted in transit, and locked to HTTPS
All traffic is HTTPS. HTTP Strict Transport Security is served with a two-year lifetime covering every subdomain, so a browser that has seen the site once will not be talked down to plaintext afterwards.
strict-transport-security: max-age=63072000; includeSubDomains
Encrypted at rest by the hosting platform
Application data is stored in Supabase Postgres hosted on AWS in ap-northeast-2, which encrypts data at rest. Backups are taken before every production schema migration.
A Content-Security-Policy that is enforced, not merely declared
The browser is prevented from loading plugin content, from having the page's base URL rewritten, from submitting forms to another origin, and from framing the application anywhere. A broader policy runs alongside it in report-only mode, so we collect evidence about what a stricter version would break before enforcing it rather than guessing.
content-security-policy: base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'
The rest of the response-header set
Clickjacking is refused outright, MIME-type sniffing is disabled, referrer information is not leaked cross-origin, and the browser features the product does not use — geolocation, payment, USB, motion sensors, advertising-interest signals — are switched off rather than left available.
x-frame-options, x-content-type-options, referrer-policy, permissions-policy
Dependencies and secrets are scanned continuously
Automated dependency alerts and security updates are enabled, and secret scanning with push protection blocks a credential from reaching the repository in the first place. A vulnerability gate runs in continuous integration and fails a change that introduces a new high-severity dependency; anything accepted instead of fixed is recorded in writing with a reason and a review date, rather than passed over in silence.
Providers are named, and separated behind an internal boundary
Outside providers that can process customer content are published, along with what each does and how long it keeps it. Every provider integration sits behind an internal adapter boundary, so no vendor SDK is reachable from business logic directly.
The response headers above are served on every request and can be checked from anywhere with curl -sSI https://app.runtheworld.ai. Verified against production on 21 August 2026.
What we do not have yet
- We are not SOC 2 certified. Readiness work is underway and we will say so here when that changes; we would rather tell you now than have you discover it in a questionnaire.
- An independent penetration test has been commissioned but not yet carried out, so there is no report to share.
- We do not run a paid bug-bounty programme. Reports go to the address above and are read by a person.
Reporting a vulnerability
Email security@runtheworld.ai with what you found, how to reproduce it, and what it lets someone do. You will get a human reply.
Please do not include real personal data, credentials, tokens, or full session transcripts in a report — a redacted excerpt, or a reproduction against your own test account, is enough to show the problem.
If you make a good-faith effort to follow this, we will not pursue legal action against you for the research. Test only against accounts you own, do not access or retain anyone else's data, and give us a reasonable chance to fix the issue before making it public.
What to expect after you report
| Stage | Target |
|---|---|
| Acknowledgement of a new report | 2 business days |
| Initial triage and severity assignment | 5 business days |
| Remediation — critical severity | 7 days from confirmation |
| Remediation — high severity | 30 days from confirmation |
| Remediation — moderate severity | 90 days from confirmation |
Related
Who else can process customer content is published at providers, and how personal data is handled at the privacy statement.
