> ## Documentation Index
> Fetch the complete documentation index at: https://docs.moxus.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Privacy and data
> Understand what Moxus AI collects, why it is needed, and how to reduce data exposure risk.
This page explains the data Moxus AI handles for accounts, billing, API calls, and security. Use it to evaluate whether the platform fits your use case and to support internal review before integration.
Moxus AI is a model gateway. Request content is forwarded to the upstream model provider you choose. Each provider may have its own data retention, training, and compliance-region rules. Review the selected provider's policy before sending sensitive production data.
## Data Moxus AI handles
| Data type | Examples | Purpose |
| --------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Account data | Username, email, account status, created time, last login time | Login, account identification, security notices, and recovery |
| Login credentials | Password hash, passkey binding data, login sessions | Identity verification and account protection |
| Third-party login IDs | Google account ID | Account binding when you use Google sign-in |
| API key settings | Key name, status, quota, expiration, model limits, IP limits, group limits | Authentication, quota control, permission isolation, and abuse prevention |
| Usage and billing data | Request count, input tokens, output tokens, consumed quota, top-ups, refunds | Billing, balance display, usage analysis, and reconciliation |
| API activity records | Time, key name, model, token counts, cost, request ID, IP, latency, stream status | Troubleshooting, cost attribution, abuse prevention, and reports |
| Request metadata | Request parameters, error messages, upstream request ID, system state | Debugging failed requests and improving stability |
| Conversation and file input | Text, images, PDFs, Markdown files, and other content you send through Conversation or APIs | Forwarded to models so they can process and answer |
## Information Moxus AI does not ask for
Moxus AI support and docs do not ask you to provide:
* Plaintext API keys.
* Login passwords.
* Payment passwords, card passwords, or verification codes.
* Private repository access tokens.
* Identity documents, contacts, or local files unrelated to model calls.
Do not put API keys, login passwords, private tokens, or production database credentials in prompts, screenshots, public repositories, or chat logs. Model request content is sent to upstream model services, and the platform cannot automatically judge whether every prompt contains sensitive data.
## How request content flows
1. Your client sends a request to Moxus AI with an API key.
2. Moxus AI authenticates the key, checks limits, reserves balance, and processes parameters.
3. The request content is forwarded to the upstream provider for the selected model.
4. After the upstream response returns, Moxus AI settles usage and records necessary activity logs.
5. You can view request activity and cost in Usage.
## Retention and visibility
| Data | Visibility | Notes |
| -------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Account profile | Current user | Used for profile, security settings, and recovery |
| API key list | Current user | Full keys are shown only once at creation; lists usually show masked keys |
| API activity | Current user | Shows request time, model, token counts, and cost summaries |
| System and error logs | User-visible summary; more diagnostic fields for administrators | Admin-only fields are stripped from normal user views |
| Upstream-processed content | Depends on provider | Request content is sent to the selected model provider; provider policy controls its retention |
## Platform protections
* Passwords are stored as hashes, not plaintext.
* API keys are shown in full only once after creation and are masked in lists.
* API keys can have quota, expiration, model, and source IP limits.
* Passkeys are supported for stronger login security.
* Admin-only diagnostic fields are hidden from normal user log views.
* Some privacy-sensitive request fields are filtered or controlled by platform settings, such as `safety_identifier`.
## What you can do
* Create separate API keys for development, production, and external tools.
* Set low quotas for browser extensions, desktop tools, and test scripts.
* Use source IP limits for server-side projects with fixed outbound IPs.
* Delete keys that are no longer used.
* Never expose keys in frontend code, public repositories, screenshots, or chat messages.
* Review the target provider's data policy before sending sensitive business data.
## If something looks wrong
Open [Usage](/en/platform/dashboard-and-usage), group by model and API key, then disable or delete suspicious keys in [API keys](/en/platform/account-and-keys).
Delete or disable the key immediately, create a new key, and update your app configuration. Then review recent API activity for unusual calls.
Change the login password, review passkeys and API keys, and delete unknown keys. If the issue continues, contact support with the time range, account email, and request IDs.
## Related docs
* [Profile and security](/en/platform/profile-and-security)
* [API keys](/en/platform/account-and-keys)
* [Usage](/en/platform/dashboard-and-usage)