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

StageTarget
Acknowledgement of a new report2 business days
Initial triage and severity assignment5 business days
Remediation — critical severity7 days from confirmation
Remediation — high severity30 days from confirmation
Remediation — moderate severity90 days from confirmation

Who else can process customer content is published at providers, and how personal data is handled at the privacy statement.

Let your team send.
Stay in control.

See who approved the first contact, what allowed a send and which customer choices stopped it. Give your team the context to act with confidence.

Explore customer privacy

Before a message goes out

  • Consent is never assumed

    A contact record is a starting point. Permission needs its own evidence.

  • Opt-outs are re-checked at the moment of sending

    An earlier approval cannot override a later opt-out.

  • A person approves every first contact

    AI can prepare the next step. A person decides whether that first message leaves.

Before a visitor is identified

  • Where a visitor is sets how far identification can go

    Local limits determine whether a visit can resolve to a company, a person or neither.

  • Global Privacy Control is honoured everywhere

    The visitor’s privacy signal comes first, wherever they are.