Developer data protection
Choose the code you share with AI
Developers should share employer-owned code only when the organisation permits that disclosure to the selected AI service and account. Start with the smallest example that still explains the problem. Remove unnecessary business logic, identifiers and configuration, and check what the client adds automatically. A provider’s no-training policy does not replace the employer’s permission.
For Engineering security and tech leads
A smaller useful example gives the data owner a clearer decision.
Fictional code and illustrative classifications. No real employer approval or protection test is implied.01
Resolve the disclosure decision first
Confirm who owns the code and who can approve its use with an external service. This guide concerns employer-owned material. Client code, contractual confidentiality and third-party licence questions can require a different review; use the linked client-code guide instead of assuming the same permission applies.
Record the service, account and purpose alongside the approval. Permission to discuss a public utility function is not permission to upload an internal repository. The relevant question is what information the task discloses, including comments, tests, data structures and names that reveal how the organisation operates.
02
Build the smallest useful example
State the programming question in one sentence before copying code. For a type error, retain the types and failing expression. For a boundary condition, retain the input and expected output. Replace unrelated business rules with neutral values and remove modules that do not contribute to the explanation.
Test whether the reduced example still demonstrates the issue using your normal local tools. If removing a value changes the question, note that trade-off for the owner. Do not silently replace a meaningful value and then treat an AI answer as if it applied to the original system.
- Retain
- The language, error, small relevant function and expected behaviour.
- Review
- Internal naming, proprietary rules, unreleased interfaces and comments.
- Remove when unnecessary
- Credentials, customer values, private addresses and unrelated files.
03
Check the context around the paste
The visible snippet may be only part of a request. An editor can add selected files, nearby definitions or repository context. A coding agent may obtain more through a tool. Record the actual client and action rather than approving a snippet while leaving the surrounding context unexplained.
Cursor’s data-governance documentation describes sending prompts and code context to model providers. GitHub also documents that indirect semantic information can reach Copilot despite some file exclusions. These sources illustrate why a code disclosure review needs both the intended input and the client’s context behaviour.
Source context: Cursor: Privacy and Data Governance · GitHub: Content exclusion for Copilot
04
Use the three synthetic examples
The download contains an elementary public-style function, a fictional internal business rule and a restricted-labelled marker. The labels are teaching categories, not legal conclusions about actual code. A completed example decision explains why a minimal mathematical example can answer the programming question without reproducing the invented business rule.
Use the blank decision sheet for your own review, but do not add real restricted code to this training pack. Record the intended account and action, owner decision and remaining context questions. The files make no API calls, include no working credentials and contain no measured product results.
| Example | Useful question | Review outcome |
|---|---|---|
| Public-style utility | How should an empty list be handled? | Illustrative candidate for an approved account |
| Fictional internal rule | What changes a private eligibility calculation? | Owner review required |
| Restricted marker | Can the client include a labelled file? | Canary only, not permission to share real code |
05
Make the approved path easy to follow
Document a short rule developers can apply: approved purpose, acceptable code class, account and client action, plus who to ask when the example cannot be reduced. Give a permitted alternative such as a synthetic reproduction, public documentation or an internal review.
Revisit the decision when the client adds repository indexing, a new model, a connector or a different execution mode. Keep the employer disclosure decision separate from security testing of a control. Both matter, and neither should be inferred solely from an assistant producing a useful answer.
Put it into practice
Permitted-snippet decision pack
Compare three synthetic code classes and capture an employer-owned disclosure decision.
Fictional code and illustrative classifications. No real employer approval or protection test is implied.
| Code class | Needed for the question? | Next step |
|---|---|---|
| Public-style utility | Small relevant function | Use an approved service/account |
| Internal business rule | Possibly reducible | Ask the code owner |
| Restricted-labelled marker | Only for an access test | Keep it synthetic and isolated |
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
# Permitted-snippet training pack
Every example is fictional. The labels do not grant permission to share real employer or client code. No file contacts an API or reads your environment.
Compare the examples, then complete snippet-decision.md. Do not replace the examples with restricted code. To discuss a real problem, first obtain the owner decision and prepare a minimal reproduction separately.
## Guide and source references
Canonical guide: https://aona.ai/resources/guides/proprietary-source-code-ai-prompts/
Source review: 2026-09-21
- Cursor: Privacy and Data Governance: https://cursor.com/docs/enterprise/privacy-and-data-governance
- GitHub: Content exclusion for Copilot: https://docs.github.com/en/copilot/concepts/context/content-exclusion
public-style-example.pyInspect
# Synthetic teaching example, no external input or network.
def total(values):
return sum(values)
# Question to review locally: what result should an empty list produce?
fictional-internal-example.pyInspect
# Entirely fictional business rule for disclosure discussion.
# Label: INTERNAL EXAMPLE, owner review required in the exercise.
def example_priority(days_waiting, contract_tier):
return days_waiting + (7 if contract_tier == "FICTIONAL_PLUS" else 0)
restricted-marker.txtInspect
SYNTHETIC_D02_RESTRICTED_CODE_MARKER
No actual proprietary algorithm or credential is present.
snippet-decision.mdInspect
# Employer-owned snippet decision
Programming question: ____________________
Code owner and permitted disclosure authority: ____________________
Service, account and action: ____________________
Minimum example needed: ____________________
Unnecessary business context removed: ____________________
Automatic context still to review: ____________________
Decision: NOT YET REVIEWED
Reviewer/date: ____________________
Illustrative example: an empty-list sum question can use public-style-example.py. The fictional contract-tier rule is not required to explain sum([]), so leave it out. This is an example of minimisation, not an employer approval.
Before you proceed
Keep these distinctions clear
- Confusing privacy terms with permission
- A service’s processing commitments do not decide whether the employer permits disclosure.
- Reducing the code until the bug disappears
- Keep enough structure to reproduce the programming issue and document what changed.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate policy outcomes for supported code-containing prompts and files on installed employee endpoints.
Aona does not decide intellectual-property ownership or authorize disclosure, and no universal repository or coding-client coverage is implied.
Bring a permitted synthetic snippet and a restricted canary to a scoped demonstration of the intended input path.
Review your use caseFAQ
Questions for this decision
Can developers paste any code if the provider does not train on it?
Does removing comments make proprietary code safe to share?
Can the synthetic examples be used as proof of DLP protection?
What if the code belongs to a 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
Explains transfer of prompts and code context to model providers.
vendor · checked 2026-09-21 - GitHub: Content exclusion for Copilot
Documents indirect semantic context and exclusion limitations.
vendor · checked 2026-09-21