API key security for coding Agents starts with a simple distinction: hiding a key from the chat window does not necessarily hide it from the process running tools. If that process can read a credential file or environment variable, an Agent with suitable tool access may be able to read it too.
This is a security checklist based on documentation reviewed September 29, 2026. It is not a security certification or a claim that any hosted Workspace makes credentials unreachable.
Separate identity, permission, and spending
A key authenticates a caller. The permissions attached to it determine allowed actions; the account's funding controls affect spending. Do not assume a new key automatically creates a separate permission boundary or hard budget.
For each integration, record its owner, environment, purpose, permitted operations, and revocation procedure. Use distinct credentials where independent revocation matters, such as development and production. Never share a personal secret merely because several developers use the same tool.
Broader isolation and membership questions belong in the coding Agent Workspace security guide. This checklist focuses on the credential's lifecycle.
Deliver secrets without making them project content
OpenAI's API-key safety guidance warns against exposing keys in client-side applications or repositories. Environment variables can reduce accidental hardcoding, but they are not a security sandbox.
Prefer an approved secret manager and a narrowly scoped execution environment. Where practical, let a trusted service attach credentials to authorized requests rather than handing the raw secret to an unrestricted tool process. Such a service still needs authentication, authorization, logging, and its own review; it is not automatically safe because it is called a proxy.
Avoid putting secrets in prompts, screenshots, debug dumps, sample configuration, or support tickets. Ignoring a file in Git only prevents some future tracking; it does not remove a secret already committed or logged.
Rehearse a normal rotation
For a routine rotation, identify every dependent job before changing anything. Check whether your provider permits old and new credentials to overlap.
- Create the replacement using the provider's supported flow.
- Update one low-risk consumer and verify a minimal request.
- Update the remaining consumers and confirm their configuration was reloaded.
- Revoke the old credential once cutover is verified.
- Check that retired jobs no longer succeed with the old secret.
If the provider invalidates the old value immediately, plan a coordinated cutover instead of assuming overlap. Never keep an exposed key alive merely to avoid downtime.
Respond differently to suspected exposure
Revoke or disable the exposed credential promptly, pause affected automation, and notify the account owner. Review usage and downstream permissions from the possible exposure window.
Remove the secret from current files and follow the repository's approved history-remediation process if it was committed. Deleting a line alone does not retract copies, logs, or caches. Preserve sanitized incident evidence without copying the live credential into another document.
Before resuming, fix the leak path: a replacement key placed in the same public bundle will leak again.
Verify access without revealing the secret
The Agent.Space Developer API guide describes dedicated keys and request-history checks. Use request identifiers and key labels for diagnosis, not full secret values. Check the current product's actual permission and funding controls rather than assuming a universal hard cap.
Open Agent.Space if you need a supported API setup. Keep credential handling separate from prompts and review the tool process's access before giving it a real project.