Security

Security at MobileAiProxy

The whole point of a proxy is to keep secrets server-side and put a verified, governed boundary in front of model spend. Here is how that boundary is built.

Last updated June 22, 2026

Keys never leave the server

Your app talks to the proxy with a public app key and a verified user token. Real provider keys are decrypted only inside the request that forwards traffic, used once, and never returned to the client. That single property removes the most common way mobile AI features leak credentials.

Encryption at rest

Provider keys and any logged payloads are encrypted at rest with AES-256-GCM, one unique nonce per record. Encryption keys are versioned, so rotation never requires re-reading plaintext.

Verified user auth

Every proxied request carries an end-user token that the proxy verifies against your auth provider (Firebase or Supabase) before any provider spend starts. Optional Firebase App Check binds a request to a known app instance.

Tenant isolation

Data is partitioned per account and per app. Database access runs under row-level security so one tenant cannot read another tenant's records, and provider secrets are decrypted only inside the request that needs them.

Policy-engine spend caps

The policy engine enforces allowed models, per-request token caps, and daily and monthly request and cost budgets before forwarding. A request that cannot be priced against a configured budget is blocked rather than forwarded, so runaway spend is contained.

Minimal data handling

Request and response logging is disabled by default. When you enable it, you choose how much is kept, it is encrypted at rest, and it expires on the retention window you set. The proxy stores ciphertext, never plaintext secrets.

Reporting a vulnerability

If you believe you have found a security issue, please report it privately and give us a reasonable window to investigate before any public disclosure. We do not pursue good-faith researchers who follow responsible disclosure and avoid accessing other tenants' data.

For how data is handled day to day, see our Privacy Policy and the Terms of Service.