Security

• Encrypted in transit. TLS from your browser to Amazon CloudFront, from CloudFront to our load balancer on Amazon Web Services, and from the application to the database, the object store and the phone hosts. From the load balancer to the application, requests stay inside a private network with no public address. The phone hosts’ certificates come from our own certificate authority, the only one the application trusts for them, and every request to a host carries a bearer token.
• Encrypted at rest. Our managed providers encrypt stored data with AES-256; that is their control. The phone hosts’ disks are encrypted as well. Saved sign-ins get a second layer of our own: the application seals each with AES-256-GCM under its own key, bound to the owning account, before storage.
• Computer runs are ephemeral and isolated. Each computer run gets a fresh remote sandbox, its own Linux desktop, destroyed when the run ends. Computer runs share nothing.
• Phone runs start from one clean image. A phone run leases an emulated Android phone on hosts we run, several phones to a host. When the run ends, the phone is restored from one clean snapshot before anyone else gets it. A phone cannot reach private or link-local addresses, the cloud metadata service included, or its own host. Calls and texts never leave the phone, and it has no Bluetooth.
• A computer run's browser is filtered. A denylist blocks localhost and private address space, and DNS is re-resolved often to limit rebinding, so the browser cannot be steered at internal infrastructure. The filter covers the browser only: agents can also run shell commands, and a program run there can open connections the filter does not see. That traffic is bounded by the sandbox itself, which is isolated and destroyed with the run.

• Saved sign-ins are never shown to a model. An agent asks for a saved sign-in by name; the system types the value and never keeps the screenshot of that moment. A battle using a saved sign-in, and every follow-up, is never offered to judges or included in a dataset, and its screenshots are kept for you alone. Revoke a sign-in at any time in your vault.
• Files you attach are kept as you sent them. Our redactors read text, and a spreadsheet or archive is not text, so files are stored unmodified with their task. Only the uploading account can download a file through the application.
• The object store is private. Screenshots live in a private bucket with a size cap and a file-type allowlist; uploaded files in a second private bucket with a larger cap. There is no public read path and no signed-URL serving; the application brokers every read.
• Uploads are checked against their own bytes. A file is accepted on what its leading bytes are, not the type your browser declared, against a closed allowlist; an executable is refused whatever its name. There is no malware scanning; in its place are the allowlist, no execution path on our servers, and per-account quotas.
• Raw IP addresses are never written to disk. They are held in memory for a request and as rate-limit keys for a limit window, and hashed before anything is written.
• The public dataset sample is stripped. No screenshots, reasoning traces or judge behaviour; capped and stratified. Every dataset package includes each step’s screenshot: the masked copy where a web page was masked, the original otherwise. The self-serve download serves no screenshot files, and battles that used a saved sign-in never ship. Phone battles are not in any dataset.
• Battles and files you cannot see answer as not found. A request for a battle or uploaded file outside your access gets a 404, which does not reveal that the record exists.

Automated check suites in the repository cover network egress policy, judging blindness, battle access control, consent integrity, share exposure and rating fairness. Their claims are published at /governance, with the file that keeps each one.

• Two people hold production access. Both founders, both US-based, both under executed confidentiality agreements. No contractors, no agencies, no crowdworkers.
• MFA everywhere, no SMS. Authenticator-app one-time codes on every personnel account: identity, source control, hosting, database, storage and sandbox consoles alike.
• Administrative routes take a separate credential. A bearer token compared in constant time, not derivable from any signed-in session.
• Endpoints are locked down. Full-disk encryption on every machine; automatic screen lock after 30 seconds of inactivity.
• Revocation is rotation. Departure means account removal across every console within 24 hours and rotation of every shared secret the person could have seen.

A run on a provider’s model sends that provider the task prompt verbatim, the unmasked screenshot of every step, whatever the agent reads from your files, and your memory note if you keep one: what a model must see to act. Masking applies to what we store and publish, not to inference.

Separately, every prompt submitted without attachments goes to OpenAI to decide how it is handled, before any agent runs and whichever models then run it. Both are part of the terms you accept at sign-in and are covered in the privacy policy.

We have had no security breach and no incident requiring notification. If one occurs, affected parties are notified within 24 hours of our becoming aware, on discovery rather than after investigation, with written follow-up as facts are established.

Report anything you find to founders@coasty.ai; both founders read it. Good-faith research on your own account will never be met with legal threats. The same contact is in security.txt.

• No SOC 2, no ISO 27001. We hold no security certification or third-party audit report. A SOC 2 readiness process is the committed next step as the company grows.
• No dedicated security team. Security is owned directly by the founders, with a named accountable owner.
• No enforced retention schedule. Most records, including attached files, are kept indefinitely. Enforced limits: sign-in sessions expire after 30 days and signed-in machine state after 7 days. The privacy policy gives each record’s retention.
• No SIEM. Application, platform and database logs exist, with deduplicated alerting to an internal channel, but no centralised aggregation or scheduled access review yet.

12 services receive data today, from the database to the model APIs. Each is listed, with what reaches it and the services not currently in use, at /subprocessors.