Restrict API key creation: what OpenAI added, and Sume's key rules
OpenAI added admin controls to restrict API key creation on 2026-09-15. Sume keys are workspace-scoped with fixed scopes and rotate by replacement.
OpenAI's changelog lists admin controls to restrict API key creation at the organization and project level on September 15. That covers OpenAI keys only. Sume manages its own: keys are workspace-scoped, their scopes are fixed when created, and rotation means creating a replacement, verifying it, and revoking the old one.
What did OpenAI change?
The changelog entry dated Sep 15 says admins can restrict API key creation at the org and project level. This post takes only that one line from OpenAI's page. Read it there for what the setting blocks and who can override it.
How do Sume keys differ?
Sume API keys are created in the API Keys dashboard and are scoped to a workspace. Scopes are fixed at creation and cannot be added later, so an older key returns 403 insufficient_scope on newer surfaces.
| Topic | Rule |
|---|---|
| Scope of a key | Workspace-scoped |
| Adding a scope later | Not possible; create a new key |
| Sending a key | Bearer or x-api-key, one only |
| Service-account keys | Cannot create Agent Completions |
What are the steps to rotate a Sume key?
Create a replacement key, deploy it to your server, verify with GET /v1/me, then revoke the old key from the dashboard. If a key appears in logs or chat history, rotate it. The verification call is the same one the authentication page uses in its examples.
Why can a service account fail on an agent run?
Sume's Agent Completions docs say service-account keys cannot create completions. They fail with 403 insufficient_scope and details.reason of service_account_agent_completions_unsupported. Format runs have the same rule with a different reason string. If your platform team is moving automation to service accounts, check this before cutting over.
What should a team check this week?
Inventory which of your integrations still use a key created before the surface they now call. Sume's docs say keys created before Agent Completions shipped do not carry agent_completions:* scopes and fail every request with 403 insufficient_scope. There is no API to patch scopes onto an existing key.
Keep keys on trusted servers or CI secret stores, never in frontend JavaScript, and give agents read-only commands first. Require explicit confirmation before write or paid generation commands, as the authentication page advises.
Do rate limits follow the key?
Every Sume key gets a per-minute request budget set by the subscription plan of its workspace, with separate read and write buckets. The Free plan lists 120 writes and 4800 reads per minute, and Pro lists 300 and 12000. Rotating a key does not change the plan budget, since the budget belongs to the workspace.
Sources
Related posts
More in Developers
- Promise.allSettled vs Promise.all for a batch of API jobs
Promise.allSettled waits for every promise and reports each outcome; Promise.all rejects on the first failure. For paid API jobs, use allSettled.
- Python API rate limiting: stay under a per-minute limit
Pace Python API calls with an asyncio limiter set under the API's per-minute budget, keep polling on its own budget, and back off on 429 retry-after.
- Python requests default timeout: there isn't one
Python Requests has no default timeout: without timeout= a call can hang indefinitely. Set (connect, read) on every call, and keep it short for job APIs.
- 429 queue_full vs rate_limited: what the generation API means
On Sume, 429 queue_full means no accepted generation capacity is left, rate_limited means request volume, and full concurrency leaves the job queued.
Written by Sume