Security and limits
Project policies, scoped credentials and bounded admission.
AI generation requires an enabled project, an active credential with ai:generate, a linked USD billing account, available credit and a reviewed permitted model. ai:read grants catalog/task/video reads. Resources remain scoped to project and tenant.
Cloud rechecks credential revocation/expiry, OAuth application and membership, project product status, tenant ownership/status and billing linkage before paid work, including queued submission. Clients cannot supply provider secrets, upstream URLs or fallback routing.
Project policy
A project owner can update AI policy through the console API:
PUT /api/v1/projects/{projectId}/products/ai/policy
This uses account authentication, not a public project API key. Policies replace the configured limit groups; use the current console API policy contract rather than a partial assumed merge. modelAllowlist: null permits all reviewed models, while [] denies generation. Owners can tighten traffic limits.
Default AI limits are 20 read requests/second (burst 40, 50,000/day) and 10 generation requests/second (burst 20, 10,000/day). Admission combines project, credential and tenant buckets with project/tenant daily quotas. Honor Retry-After. Daily resets use Africa/Algiers; monthly spend uses UTC.
Runtime bounds
The gateway limits bodies to 20 MiB, upload time to 45 seconds, and provider JSON/audio/SSE buffers to 32 MiB. Provider concurrency defaults to 32 shared slots, with 8 background workers. These are operator-configurable deployment limits, not a latency guarantee. Reads and streams do not trigger automatic paid retries.
Failed control, quota or financial-state checks stop paid submission. Do not assume a Redis reset clears debt or grants fresh credit. Keep long-lived credentials server-side; the trusted playground holds them in memory only.