LEGAL
Security
Where to report a problem, what we do when something goes wrong, and what we keep in our logs. The shortest true summary of our data posture: the safest prompt is the one nobody stored, so we store none.
Reporting a problem
Email yoda@yodalai.xyz. Tell us what you found, how to reproduce it, and how to reach you. We acknowledge within 2 business days.
- Test only against your own account and your own keys. Do not access another account's data, run denial-of-service tests, or use social engineering against anyone.
- Give us a reasonable chance to fix the problem before publishing it. We will not pursue a reporter who follows this.
- We do not run a paid bug bounty. We will credit you if you want to be credited.
- If you believe a key is compromised, say so in the subject line. We revoke first and investigate after.
What happens in an incident
We follow a written runbook. In customer terms, it is five steps and they happen in this order:
- Admission is stopped first. Before anything is investigated, provider dispatch and payment collection are switched off. Serving already closes itself when readiness or backup checks fail, so the safe state is the default rather than a decision made under pressure.
- Evidence is preserved. No log, ledger row or backup archive is deleted or truncated, and an older backup is never restored over newer financial events. That means we can tell you afterwards what actually happened rather than what we think happened.
- Requests in an unknown state are reconciled. A request interrupted mid-flight is settled against the provider's own record of it, never by re-running the work. You are not charged twice for one interruption, and a charge that really happened is not quietly dropped.
- Affected credentials are rotated. Each credential has its own rotation procedure and its own known side effects — some sign everyone out, some need a coordinated deploy. Those are planned, not discovered during the incident.
- You are told. We notify the affected account once admission is stopped and evidence is preserved, and we do not describe anything as resolved until the verification steps for that rotation or reconciliation have actually passed.
Where an incident affects your data, we will tell you what we know, what we do not yet know, and when we will next update you. Where it is an eligible data breach under the Privacy Act, we notify you and the Office of the Australian Information Commissioner as that scheme requires.
What we log, and what we do not
| Logged | Never logged |
|---|---|
| Request, job and attempt identifiers, and the account, client, customer and project they belong to | Prompt text, system prompts and message content |
| The model route served, token counts in and out, and the exact charge in AUD | Completion text, streamed or not |
| Timestamps, outcome and refusal codes, and provider request identifiers for reconciliation | Tool arguments and tool results |
| Sign-in events, workspace membership changes and key creation, rotation and revocation | API keys and passwords — only hashes are stored |
| Errors and stack traces from our own code | A plain digest of a request body. The fingerprint that binds a retry is keyed, so it cannot be used to recognise content |
Controls a reviewer usually asks about
- Keys. Shown once, stored as hashes, scoped to one project and environment, revocable and rotatable. A project key is never accepted on an operator or workspace API.
- Account isolation. Enforced in the gateway at the point of admission, not in the frontend. A client sees only its own customers.
- Spending. Per-request, monthly, concurrency and credit ceilings refuse admission rather than letting spend run.
- Two-factor authentication. Available on workspace accounts, and required for operator access.
- Backups. Both databases are backed up and the backups are verified. If the last verified backup goes stale, serving closes itself rather than running unprotected.
- Transport. HTTPS everywhere, with the portal refusing to talk to a gateway URL that is not HTTPS.
- Dependencies. Production dependencies are audited in CI, and a high or critical advisory fails the build.
Residency is on the data residency page; suppliers are on the subprocessors page.
Modelvia is a single-instance private pilot. See service levels for what that means for availability, and status for what the gateway is reporting right now.