Developer data protection
Protect company data in AI coding
Start by mapping how a developer’s task sends data to AI: typed prompts, selected code, repository context, terminal output and connected tools. Approve the data and account, choose controls for each path, then run a small synthetic pilot. A tool name or no-training statement alone does not establish that company data stays within your intended boundary.
For CISO and engineering leader
Choose the workflow before choosing the control.
Synthetic planning examples. No installed-product tests or results are included.01
Start with a real engineering task
Pick a task your team already wants to complete: explain a build failure, improve a public utility function or draft a test. Name the developer, approved client and repository owner. This turns “allow AI” into a decision that engineering and security can review together. A pilot covering one local editor does not automatically approve its command-line or cloud agent.
Record what the task needs and what it can do without. A stack trace may need an exception name and two frames, but no customer record. A code explanation may need a short function, but no internal configuration. Agree the minimum useful input before adding controls.
Source context: Cursor: Privacy and Data Governance · OpenAI: Agent approvals and security
02
Follow the information into context
A developer can intentionally paste a snippet while the client supplies additional context. Repository search, an attached file, a shell result or a connected service can introduce material that was absent from the original prompt. Ask where each read happens and which system receives the result.
Use the map below to identify a control owner. Employer permission governs disclosure. Client permissions govern access. Provider terms govern processing and retention. Endpoint controls may evaluate supported submissions. Each answers a different part of the buying question.
| Source/input | Client/runtime | Recipient or boundary to identify | Review owner |
|---|---|---|---|
| Selected code or log | Browser or editor | Model provider and retained transcript | Data owner and endpoint security |
| File or terminal result | Local agent | Context sent by the selected client | Developer platform and client administrator |
| Connected service data | MCP or app tool | Service, tool result and model context | Service owner and identity administrator |
| Repository clone | Cloud agent environment | Cloud disk, model provider and snapshots | Cloud and repository owner |
Source context: Cursor: Privacy and Data Governance · OpenAI: Agent approvals and security
03
Choose a control for the exposure
For restricted source files, start with access and context controls. For unnecessary identifiers in an otherwise useful log, minimise the input and evaluate the supported submission path. For an external connector, review its identity and permissions. Moving a task to a cloud agent introduces a separate execution environment rather than extending the laptop’s boundary.
Keep controls complementary. A no-training commitment does not authorize an employee to disclose proprietary code. A filesystem rule does not describe every connected service. A recorded AI event does not prove that a policy evaluated or blocked its content.
- Permitted work
- Specify data classes and approved accounts so developers know what they can use.
- Restricted data
- Identify both the source location and the path through which it could enter context.
- Evidence
- Define the observable result before choosing a test or interpreting an event.
Source context: Cursor: Privacy and Data Governance · OpenAI: Agent approvals and security
04
Build a small, useful pilot
The download contains a task-selection sheet, a data-path register and four obviously synthetic markers representing code, secrets, logs and repository context. They contain no customer information or working credentials. They help organise a test; they are not proof that a detector recognises a real data class.
For each selected path, write the policy you intend to exercise, its prerequisite and the expected employee experience. Ask the control owner whether the fixture can trigger that policy. Keep the observed result blank until a real test is performed. Record allowed, denied, approval requested or not evaluated, with the client version and evidence location.
Source context: Aona: AI security coverage
05
Approve the scope you can support
Close the pilot with a narrow decision: approved task, data classes, account, client, environment and responsible owner. An unexplained result is a reason to investigate that path, not a reason to label the whole product safe or unsafe. Link the detailed client tests when the team needs them.
Revisit the decision when developers add a CLI, change models, connect a service or move a repository into a remote environment. Keep a useful permitted path available while resolving a restricted one. That makes the outcome an operational agreement rather than a policy document nobody can follow.
Put it into practice
Developer data-path pilot pack
Select one task, assign its control owners and record a scoped pilot decision.
Synthetic planning examples. No installed-product tests or results are included.
| Input source | Client/runtime | Recipient and retained copy to review |
|---|---|---|
| Synthetic code | Selected editor or CLI | Model destination and transcript |
| Fake secret marker | Supported test input path | Control boundary before submission |
| Synthetic test trace | Paste or file upload | Provider request and retained history |
| Repository marker | Context or file-reading tool | Tool result and downstream context |
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
# Developer data-path pilot
All values are synthetic. Use an isolated test repository and an approved test account. No file runs commands, contacts a service or configures a product.
1. Choose one task in pilot-decision.md.
2. Complete the client and owner fields in data-path-register.csv.
3. Select only the relevant labels from synthetic-pilot-markers.json. They are not real credentials and may not trigger a data classifier. Agree a supported test rule or representative safe fixture with its owner.
4. If you manually test an approved AI client, use only these synthetic inputs. Record what actually happened and preserve the exact scope.
5. Route deeper client-specific questions to the linked guides; do not broaden the pilot by adding new accounts or connectors.
## Guide and source references
Canonical guide: https://aona.ai/solutions/ai-data-security-for-developers/
Source review: 2026-09-21
- Cursor: Privacy and Data Governance: https://cursor.com/docs/enterprise/privacy-and-data-governance
- OpenAI: Agent approvals and security: https://learn.chatgpt.com/docs/agent-approvals-security
- Aona: AI security coverage: https://aona.ai/resources/ai-security-coverage/
data-path-register.csvInspect
task,input_source,input_path,data_owner,client_and_version,execution_location,recipient_or_destination,retained_copy_to_review,control_boundary,intended_control,expected_outcome,observed_outcome,evidence
Explain a synthetic test failure,toy test trace,pasted log,ASSIGN,RECORD,RECORD,RECORD,client and provider history,DEFINE,SELECT,DEFINE,UNTESTED,
Explain a synthetic function,toy function,selected code,ASSIGN,RECORD,RECORD,RECORD,client and provider history,DEFINE,SELECT,DEFINE,UNTESTED,
Find a synthetic marker,fixture folder,repository context,ASSIGN,RECORD,RECORD,RECORD,tool result and downstream context,DEFINE,SELECT,DEFINE,UNTESTED,
Review a connected response,approved synthetic service data,approved tool only,ASSIGN,RECORD,RECORD,RECORD,service log and model transcript,DEFINE,SELECT,DEFINE,UNTESTED,
synthetic-pilot-markers.jsonInspect
{
"notice": "Synthetic labels only. No credential, customer record or test result.",
"code": "def synthetic_total(values): return sum(values)",
"secret": "NOT_A_CREDENTIAL_D01_CANARY",
"log": "SYNTHETIC_D01_TEST_TRACE\n File test_total.py, line 6: synthetic_total(None)\n File example.py, line 2: return sum(values)\nTypeError: NoneType object is not iterable\nExpected test behaviour: return 0 for an empty input; decide separately whether None is valid.",
"context": "SYNTHETIC_D01_CONTEXT_MARKER"
}
pilot-decision.mdInspect
# Pilot decision
Task: ____________________
Business purpose: ____________________
Permitted inputs: ____________________
Restricted inputs: ____________________
Account, client/version and OS: ____________________
Local, remote or cloud execution: ____________________
Expected control and prerequisite: ____________________
Observed result: UNTESTED
Evidence location: ____________________
Decision: NOT YET REVIEWED
Owner and review date: ____________________
Recheck triggers: new client, model, connector, repository location or policy.
Before you proceed
Keep these distinctions clear
- Approving a brand
- Approve a task and client configuration. The same brand can expose editor, CLI and cloud paths.
- Calling a marker a DLP result
- A fake label tests access only unless a suitable policy trigger has been established.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate sensitive-data protection and policy outcomes on supported, installed employee endpoint paths.
Native controls vary by provider, release and input path. Agent inspection is limited rollout; this pack does not imply agentless cloud protection.
Bring the completed data-path register and one synthetic task to a scoped developer data-protection demo.
Review your use caseFAQ
Questions for this decision
Should we ban every AI coding assistant until the pilot ends?
Does no training mean the code stays on the laptop?
Can we reuse one result for every developer?
Does this pack prove Aona protects our coding client?
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: Privacy and Data Governance
Distinguishes local-client data requests, provider handling and cloud-agent environments.
vendor · checked 2026-09-21 - OpenAI: Agent approvals and security
Separates sandbox, approval and network controls for local and cloud use.
vendor · checked 2026-09-21 - Aona: AI security coverage
Current public distinction between supported endpoint policy paths and limited-rollout agent inspection.
vendor · checked 2026-09-21