Secure your developer account

Open Settings in the organization you intend to protect. Review sign-in methods, passkeys, two-factor authentication, browser sessions and CLI authorizations. Open API keys separately for application credentials. A key authenticates API calls and does not create a browser session; a CLI OAuth grant lets the CLI manage permitted account operations and is not itself an inference key.

Use a distinct key name per workload so you can identify which application to update or revoke. The key page shows its safe metadata and default permissions; its one-time raw value belongs in a protected store. Review access after a staff or device change, not only after a failed login.

Review access deliberately

Check each active browser session or device against one you recognize. Review CLI authorizations separately, including a workstation you no longer use. The list does not store a computer name. When several CLI authorizations cannot be matched, use Revoke all CLI access in Settings. Then inspect key names, state, expiry and last use when available. A key with an unfamiliar name or unexpected recent use deserves investigation even if your browser sessions look normal. Use API Activity to compare safe operation metadata without looking for prompt content.

Last use and the recent Activity list are leads, not a complete historical audit. Activity currently shows the latest 50 operations and does not filter by key. Preserve the approximate time and public request ID from your client for a focused investigation.

Respond to a lost device or key

Revoke the affected browser session, CLI authorization and individual API key as appropriate. These are separate actions: logging out of one browser does not revoke an application key, and revoking an application key does not revoke every CLI grant. For a lost key, create a replacement, update every client that used it, test the replacement with the free model catalog, and revoke the old value. For a suspected leak, revoke the exposed key promptly and complete client recovery with a new one. Review last use in the key list; it is metadata, not request content.

If the device is unavailable, act from another trusted session: end its browser session, revoke its CLI grant when you can identify it, and revoke keys stored for its clients. If several CLI grants cannot be matched to the device, revoke all of them and reauthorize only trusted workstations. Do not wait to retrieve the device before containing a known exposed key. Once access is restored, confirm the replacement client can read the free model catalog and that the old key is no longer active.

Keep diagnosis safe

Keep credentials out of code, shell history, URLs, screenshots, issue reports and support messages. Share a public request-id, time, endpoint and safe error code instead. Developer-data privacy explains how to prepare a report. For CLI storage and guarded config revert, see CLI security; for the web key lifecycle, see create and protect an API key.