At a glance

We don't train on your traffic and prompts for anyone but you.
Your traffic is stored and processed in the United States.
Traffic is encrypted in transit with TLS 1.2 or higher.
The provider keys you give us are encrypted per organization with AES-256-GCM under AWS KMS.
Going over a plan limit never blocks your traffic.
Scoring runs after the response returns, so it never changes a request or adds latency.
You can delete a use case and its traffic at any time.
We have no SOC 2 report yet. We fill in security questionnaires on request.

What happens to a request?

Your app sends its LLM request to gate.three.dev instead of straight to the provider. The proxy forwards it to your provider, on your account, and streams the answer back to your app unchanged. After the response returns, three.dev records the request and the response. Scoring runs later, in the background, on a sample of the recorded requests.

We don't publish a figure yet for the time the proxy adds to a call. We will add it to this page once we have measured it in production.

What if something goes wrong?

Recording is slow or fails: your app still gets its answer. The proxy records each request after the response, on its own task, and drops the record rather than hold up your call.
You go over a plan limit: the proxy keeps forwarding every request to your provider. Past the data limit, three.dev stops recording requests. Past the scored requests limit, it records them but stops scoring them.
The use-case header is missing or wrong: the request is forwarded and your app gets its answer, but three.dev does not record it. The setup page in the app shows the problem.
The three.dev key is missing or wrong: the proxy refuses the request with a clear error code and does not send it on. The list of proxy errors gives each code and its fix.
Your provider returns an error: the proxy passes it to your app unchanged.
gate.three.dev can't be reached: the call fails, as it would if your provider were down. The proxy has no automatic fallback. Keep your provider's address in your config: one change sends your calls straight to the provider again.

We don't offer an uptime SLA yet. status.three.dev shows whether the proxy, the app and API, and the MCP server are up, and lists past incidents.

Where is the data stored?

In the United States: AWS in us-east-1 for the app and the main database, ClickHouse Cloud for the analytics store, and RunPod for the specialized models we build for you. Cloudflare carries traffic at its edge but does not store it. If you route through OpenRouter, it picks the upstream provider, so ask us to turn OpenRouter off if you need a closed list. The subprocessors page lists every vendor and whether it receives your traffic.

Who can read your users' text?

three.dev engineers who need it to run and support the service. Each uses a named account behind single sign-on with two-factor authentication. Access ends when someone leaves or changes role.
The model providers we use on our own account to score requests and name failure modes (Anthropic, OpenAI, and Google Gemini). The same no-training commitment covers that content.
Your own model providers, on your account, under your agreement with them.

Request and response bodies are never written to our logs. One exception: when a provider returns an error, we log the error as it came, and it can quote part of the request. The subprocessors page explains this path.

Do you train on my traffic?

No. Your traffic and prompts are used only to run three.dev for you. We don't use them to train, fine-tune, or improve any model, dataset, or feature that another customer or the public gets. We do use evaluation signal, such as pass and fail results and how failures group, to make three.dev better for every customer. Section 5 of the privacy policy says exactly what that covers.

Personal and sensitive data

three.dev records requests as your app sends them, so personal data your users type can be in them. The DPA covers that data. three.dev is not for health data (PHI) or government workloads yet.

How long do you keep it?

Traffic: for the life of your subscription, or until you delete the use case. Nothing expires on a timer.
Deletion: you delete a whole use case, not single requests. When you cancel or ask us in writing, we delete your traffic within 30 days and confirm it in writing on request.
Backups: deleted on their normal 30-day rotation.
Logs: up to twelve months.

How is it protected?

TLS 1.2 or higher for all data in transit.
Encryption at rest for object storage and the analytics store.
Provider keys encrypted per organization with AES-256-GCM under AWS KMS.
Each customer's traffic is kept logically separate.
Two-factor authentication on source control and cloud console access.
Dependency scanning for known vulnerabilities on every change and every day, with automatic pull requests for security updates.
Backups of the main database and object storage, kept 30 days.

Section 7 and Annex II of the DPA are the full list.

Certifications and reviews

We have no SOC 2 report or other certification yet. We fill in security questionnaires and sign our DPA. If a breach affects your data, we tell you within 72 hours of learning of it. Email legal@round3.ai to start a review.

Report a security issue

Email legal@round3.ai. Our security.txt has the same contact.

Security and trust