Security and data
What happens to a request, and what does not.
One page for your security team and your legal team. Everything here is current policy, not aspiration. Ask for the security questionnaire or a data processing agreement any time.
The request path
Your client
Sends the request with your Seedrise key over TLS.
Seedrise gateway
Checks the key, budget, model allow-list and IP allow-list. Logs metadata. Picks a route inside the regions you allow.
Model provider
Runs the model under the provider's own terms. Output returns the same way.
Data handling
| Prompt and output content | Not stored by Seedrise. It passes through the gateway and is not written to disk or logs. |
| Training | Never. Neither Seedrise nor, under our provider terms, the model providers train on API traffic. |
| Request metadata | Model, token counts, timestamps, status, key ID, request ID. Kept for billing, audit and abuse prevention. |
| Retention of metadata | Kept for the account's life plus the period required for tax records under Australian law, then deleted. |
| Zero-retention routing | Available on request for models whose provider supports it. Set per key. |
| Provider-side retention | Some providers retain content for a limited period for abuse monitoring. We label those models and can exclude them for your keys. |
Encryption and access
In transit
TLS 1.2 or higher on every hop, client to gateway and gateway to provider. HTTPS only; plain HTTP is refused.
At rest
Account data and metadata are encrypted at rest. Keys are stored hashed and shown in full only once, at creation.
Who can see what
Operational access is limited to named staff, logged, and used for incidents and billing. Nobody reads prompts; there are none to read.
Key and account controls
- Every key can be limited by budget, model allow-list, IP allow-list and expiry date, and disabled or rotated at any time.
- Keys are created per project or environment, so spend and incidents are isolated.
- The console supports two-factor authentication and passkeys. Company accounts are opened by Seedrise; there is no self-serve signup.
- Companies are isolated from each other. No usage, keys or settings are visible across accounts.
- Usage logs per key are available in the console and as exports for your own audit.
Regions
Selected models can be pinned to Australian regions (Sydney, Melbourne). Every other model is labelled with the region it runs from, and you can exclude any region for a key. Details and the per-model list are on the data residency section and in the model library.
Sub-processors
Seedrise uses cloud infrastructure and model providers to deliver the service. By category and country:
| Category | Countries | Purpose |
|---|---|---|
| Cloud infrastructure | Australia, Japan, United States, Singapore | Gateway, console, billing systems |
| Model providers | United States, Australia, Singapore, Europe | Inference, under each provider's API terms |
| Email and support tooling | United States, Australia | Transactional email, support conversations |
The named list is provided under NDA or with a data processing agreement. Overseas disclosure is handled in line with the Australian Privacy Principles (APP 8).
Compliance, honestly
| Australian Privacy Act 1988 (APPs) | Our privacy practices follow the Australian Privacy Principles. See the privacy policy. |
| Data processing agreement | Available on request; standard on Committed plans. |
| SOC 2 / ISO 27001 | Not yet certified. We can share our control descriptions and answer your questionnaire. |
| Provider policies | Your use must follow the usage policies of each model's developer. See the acceptable use policy. |
Responsible disclosure
Found a vulnerability? Email [email protected]. We acknowledge within two business days and keep you updated until it is fixed. Machine-readable contact: /.well-known/security.txt.