Security & Data
Clear, product-specific answers about how OfoxAI protects requests and handles customer data.
Last reviewed: August 14, 2026. See the Trust Center for the overview and Subprocessors for the current provider list.
Standard API data handling
Zero Data Retention (ZDR)
ZDR applies to the standard synchronous model API. Prompt and response bodies are processed to complete the request and are not persisted by the Ofox gateway in application logs or databases.
Operational records may include account and API-key identifiers, the requested model and provider, token usage, cost, latency, status, request identifiers and errors. These records support service operation, billing, reliability, security and abuse prevention.
Model training
OfoxAI does not use prompts or responses sent through the standard model API for model training.
The selected upstream provider receives the request content needed to return a result. Its applicable terms and data practices depend on the model and active route.
Playground and asynchronous jobs
| Service | Content handling |
|---|---|
| Standard synchronous model API | Prompt and response bodies are covered by ZDR and are not persisted by the Ofox gateway. |
| Playground text | Text turns remain in the active page and are not stored as server-side conversation history by Playground. |
| Playground image and video | The latest turn may remain in the signed-in user’s browser for up to 24 hours so a paid result or running task can be recovered. Generated media, task IDs and result links may use temporary storage during that period. |
| Video API and other asynchronous jobs | Prompts, request parameters, task state and result references are retained while the job is processed and made available to the account. |
Security controls
Encrypted request path
API traffic uses TLS from the customer to Ofox and from Ofox to the selected upstream provider. The Ofox gateway authenticates the API key, applies limits, meters usage and selects the route.
API key protection
- A new API key is displayed once when it is created.
- Server-side validation uses a hash instead of readable full-key storage.
- Keys can be separated by workload, rotated and revoked.
- An IP allowlist can restrict where a key is accepted.
- Separate keys and usage budgets help contain and monitor workloads.
Keep API keys out of browser code, mobile application bundles, public repositories and screenshots. Revoke and replace a key if exposure is suspected.
ZDR-aware telemetry
Standard API prompt and response content is excluded from gateway message logs and persistent prompt storage. Error handling redacts message content, while operational telemetry focuses on routing, identifiers, usage, cost, latency, status and errors.
Access and abuse protection
Current controls include rate limits, bot protection, identity-aware administrative access, API-key rotation and revocation, optional IP allowlists, provider-aware routing and public service-status monitoring.
Upstream model providers
Ofox sends request content only to the provider serving the selected model route; it does not send each request to every listed provider. Current model providers and service providers are listed on the Subprocessors page .
Processing location varies by product, selected route and provider-controlled infrastructure.
Analytics and monitoring
The public website uses Google Analytics 4 through Google Tag Manager for usage measurement. Ofox web applications use Sentry for error and performance monitoring and sampled session replay. Sentry replay is configured to mask text and block media. These tools do not process standard model API prompt or response bodies.
GDPR
OfoxAI complies with the GDPR requirements that apply to the personal data it processes, including data minimization, purpose limitation, security safeguards and support for data-subject rights.
Reliability and fallback
OfoxAI publishes 99.99% availability for its platform. Current platform and individual model-route health is available at status.ofox.ai .
On supported OpenAI, Anthropic and Gemini request paths, customers can explicitly provide an ordered list of up to three fallback models through extra_body.provider.fallback. After an upstream error, the gateway tries those alternatives in order. See Fallback — Automatic Model Switching for configuration details.
Contact
Send privacy requests, security questions and vulnerability reports to hi@ofox.ai. Include enough information to identify the relevant account and request, but do not send API keys, passwords or unnecessary sensitive content.
The machine-readable security contact is published at security.txt .