Developer data protection
Follow the code beyond your API key
Bringing your own API key does not necessarily send code directly from the editor to only your chosen provider. Trace the editor backend, optional gateway, model service and connected tools for the feature being used. For example, Cursor documents routing BYOK requests through its backend for final prompt building and applying the chosen provider’s data-handling policy.
For Security architect and engineering procurement
Record every recipient and the data each hop receives.
Synthetic route illustration with an optional gateway branch. No network requests or configuration changes are performed.01
Separate the key owner from the recipient chain
An API key identifies an account or authorises a request. It does not, by itself, describe every system that constructs, forwards, logs or processes that request. Record the exact coding tool, feature and provider route before deciding who receives company code.
Use Cursor as a concrete documented example, not a universal architecture for all editors. Its BYOK documentation states that requests pass through Cursor’s servers for final prompt building and that the key is sent to its backend over encrypted connections. The same page states the key is not persisted after the request. These are vendor statements, not an independent traffic or storage test.
Source context: Cursor: Bring your own API key
02
Check which features actually use the key
A tool may use your key for selected model requests while other features use built-in services. Cursor documents custom keys for chat models while Tab completion continues to use its built-in models. An approved key therefore should not be treated as approval of every feature or recipient in the application.
Record each feature that developers intend to use. Include automatic context gathering and any configured external tools in the discussion, but do not assume they all follow the same route. Where the tool cannot establish a recipient or purpose, keep that field unresolved and obtain a current supported answer.
Source context: Cursor: Bring your own API key · Cursor: Privacy and Data Governance
03
Draw the actual data and credential paths
Start with the device and list the systems that receive code, prompts or tool results. Draw the credential path separately: a gateway might hold the provider credential while receiving prompts from the editor, or the editor might forward a supplied key. The distinction matters for who can inspect logs and who must revoke access.
The downloadable map is a synthetic review aid. Its optional gateway is a branch to verify, not a claim that every BYOK setup contains one. Add the organisation’s actual recipients only after the responsible owner confirms the arrangement, without entering key values or confidential payloads.
| Recipient | Question about code | Question about credentials |
|---|---|---|
| Editor backend | Does it construct or forward the prompt? | Does the key pass through or persist? |
| Configured gateway | Does it log or transform content? | Which identity reaches the provider? |
| Model provider | Which processing and retention terms apply? | Who owns and can revoke the key? |
| Connected service | What tool data crosses this boundary? | Which separate grant authorises access? |
04
Attach handling terms to each recipient
Cursor explicitly says its zero-data-retention policy does not apply to requests made with your own keys; the chosen provider’s policy applies. Review the actual provider account and agreement, rather than copying the terms of the editor’s built-in model path.
A custom gateway or connected service has its own logs, permissions, processing and retention questions. Keep these separate from a regional-hosting preference or an encryption statement. The worksheet asks who receives which data and what happens to it, so the answer remains useful even when a supplier or deployment changes.
Source context: Cursor: Bring your own API key · Cursor: Privacy and Data Governance
05
Close the route review with an owner
Approve the named feature and recipient chain, permitted code class, key owner and review date. Identify who can change the gateway URL, provider or tool connection. A configuration change that adds a new recipient should reopen the decision before restricted code follows that route.
Use only synthetic markers when reviewing a request example. This guide does not ask you to make provider calls, expose a key or capture a real developer conversation. Evaluate supported employee endpoint controls separately, and do not infer that they change the gateway or provider’s handling terms.
Put it into practice
BYOK recipient and credential map
Follow code and credentials through the selected editor, gateway and provider arrangement.
Synthetic route illustration with an optional gateway branch. No network requests or configuration changes are performed.
Code context
Client → editor backend → selected model provider
Documented Cursor BYOK example
Optional gateway
Insert only if your configuration actually uses one
Verify payload and log handling
Credential
Record which system receives the key or upstream identity
Never put the value in the map
| Hop | Data to identify | Evidence owner |
|---|---|---|
| Client → editor backend | Prompt/context and any credential forwarding | Tool administrator |
| Optional gateway | Payload, logs and provider identity | Gateway owner |
| Model provider | Input/output handling and key scope | Provider-account owner |
| Connected tools | Separate data and grants | Service owner |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
README.mdInspect
# BYOK recipient review
Inert planning files only. No provider calls, credentials or active gateway configuration are included. Cursor is a documented example; other products need their own current sources.
Use recipient-register.csv to record the actual feature and route. synthetic-route.json labels code and credential paths without values or working endpoints. An optional gateway is not assumed to exist. Review each recipient’s terms and owner before approving company code.
## Guide and sources
Canonical guide: https://aona.ai/resources/guides/ai-coding-byok-gateway-data-flow/
Source review: 2026-09-21
- Cursor: Bring your own API key: https://cursor.com/help/models-and-usage/api-keys
- Cursor: Privacy and Data Governance: https://cursor.com/docs/enterprise/privacy-and-data-governance
recipient-register.csvInspect
feature,hop,recipient,code_or_tool_data_received,credential_received_or_referenced,logging_and_retention,source,owner,status
RECORD,editor backend,RECORD,RECORD,RECORD WITHOUT VALUE,RECORD,,ASSIGN,UNVERIFIED
RECORD,optional gateway,RECORD OR NOT APPLICABLE,RECORD,RECORD WITHOUT VALUE,RECORD,,ASSIGN,UNVERIFIED
RECORD,model provider,RECORD,RECORD,RECORD WITHOUT VALUE,RECORD,,ASSIGN,UNVERIFIED
RECORD,connected service,RECORD OR NOT APPLICABLE,RECORD,RECORD WITHOUT VALUE,RECORD,,ASSIGN,UNVERIFIED
synthetic-route.jsonInspect
{
"notice": "SYNTHETIC MAP ONLY; NOT AN IMPORTABLE CLIENT CONFIG",
"feature": "TO_RECORD",
"payload_label": "SYNTHETIC_D13_CODE_CONTEXT",
"credential_label": "LABEL_ONLY_NOT_A_KEY",
"hops": [
{
"name": "editor backend",
"evidence": "TO_RECORD"
},
{
"name": "gateway",
"present": "TO_VERIFY_OR_NOT_APPLICABLE"
},
{
"name": "model provider",
"evidence": "TO_RECORD"
}
],
"network_requests_performed": false
}
approval.mdInspect
# BYOK route decision
Feature and client/version: ____________________
Approved recipient chain: ____________________
Provider-account/key owner (no key value): ____________________
Gateway/configuration change owner: ____________________
Permitted code and purpose: ____________________
Logging and retention evidence: ____________________
Connected-service review: ____________________
Decision: NOT YET REVIEWED
Recheck when provider, gateway, model, feature or connection changes.
Before you proceed
Keep these distinctions clear
- Treating billing control as recipient control
- Who pays for a model request does not identify every system that receives its context.
- Reusing built-in model terms for BYOK
- Check the provider arrangement for the actual key-based path and each additional service.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate supported employee endpoint submissions within the selected data path.
Aona does not change a gateway or provider’s retention terms, and a laptop installation does not imply control over every server-side hop.
Bring the recipient map and a permitted synthetic request to a scoped endpoint evaluation.
Review your use caseFAQ
Questions for this decision
Does BYOK mean the editor vendor never receives the request?
Does Cursor’s zero-retention policy apply to my own provider key?
Will all coding features use the key I add?
Should the review worksheet include a real token?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- Cursor: Bring your own API key
Documents backend routing, key handling, feature scope and BYOK retention-policy differences.
vendor · checked 2026-09-21 - Cursor: Privacy and Data Governance
Describes provider data flows and separate gateway/connected-service considerations.
vendor · checked 2026-09-21