Issue keys narrowly
Give each integration the smallest access it needs, keep ownership clear, and revoke a key when a team member or environment changes.
CODING AGENT API SECURITY
Make the trust boundary explicit.
Before you connect a coding tool, write down what crosses the gateway, who can issue a key, what your team needs to retain, and how you will revoke access.
Built around a stable OpenAI-compatible request shape.
REQUEST LEDGERillustrative
route /v1$0.42
in prompt context18.4k
out model output2.1k
↺ cached context6.8k
latency windowyour data · your keys
Keep keys out of clients
Server-side coding tools can read an environment variable. Browser bundles, screenshots, logs, and committed files are the wrong place for a bearer key.
Decide your log boundary
Before production, identify which request metadata your client retains and whether prompts or tool output enter any shared logging path.
Design for a failed request
Handle timeout, rate limit, and non-2xx responses without an automatic retry storm. A safe fallback is part of the integration.
A REVIEWABLE CHECKLIST
Ask these questions before the first team rollout
The answers belong in your own security review because they depend on your tool, repository, users, and account configuration.
01Where is the key created?
Document the console boundary and owner.
02Where can the key appear?
Check shell history, CI logs, crash reports, and screenshots.
03How do you revoke it?
Test the path before an incident makes it urgent.
04What data leaves your environment?
List prompts, repository context, and tool output.
i
This page describes questions and boundaries. It does not make a retention, compliance, or zero-log promise for an API account. Check the current service terms and your account configuration before sending sensitive material.
THREAT MODEL
Follow the key and the data
Security review becomes concrete when you list what can be exposed, where it can travel, and which action stops the exposure.
| Boundary | Question | Control to document |
|---|---|---|
| Key | Who can create and revoke it? | Owner, scope, rotation and revocation path |
| Client | Where can it be logged? | Shell history, CI output, crash reports |
| Prompt | What repository context leaves the environment? | Approved data classes and redaction rules |
| Gateway | What response is retained by the client? | Log fields, retention and access review |
| Failure | What happens after timeout or 429? | Bounded retry and operator-visible stop |
INCIDENT PLAYBOOK
Prepare the first ten minutes
A short, written response path is more useful than a generic promise. Keep it close to the integration owner and test the revocation step before it is urgent.
- 01
Stop new traffic
Disable the affected client or environment while you establish scope.
- 02
Revoke the key
Use the documented console path and record who performed it.
- 03
Check the boundary
Review logs, CI output, and recent task context for exposure.
- 04
Issue a replacement
Update only the intended environment, then run a small verification task.
DATA DECISIONS
Do not let a security page make a product promise
Retention, compliance, regional processing, and provider terms depend on the actual service configuration and account. Treat this page as a review checklist, then use the current console terms and your own data policy for the decision.
If a repository contains secrets or regulated data, remove or isolate it before connecting a coding tool.