Imagine a team whose AI coding assistant passes its tests when developers submit selected functions through an editor integration. The next request is to connect a private repository for indexing, giving another service access to context developers did not select.
The tests support the coding workflow they evaluated. They leave retention, training use and terms coverage across the two integrations unresolved.
I would permit a public-code sandbox only when its handling terms are acceptable and private context can be excluded. Private-repository indexing needs a separate data-use decision, with material questions resolved before access is granted.
Selected-function approval does not cover repository indexing
A useful approval identifies the content, workflow, deployment mode and account configuration. A vendor-wide “approved” label leaves too much unstated.
For the example team, the change from selected functions to repository indexing is the reason to reopen review. The second workflow needs its own assessment of what it sends and which terms govern it, even if both integrations carry the same product name.
Define these boundaries:
- Content: Public code, private source, repository metadata, credentials or production-derived material.
- Workflow: Selected-text assistance, automatic context collection, repository indexing or automated review.
- Processing: The evaluated deployment mode, service endpoints, processing locations and applicable subprocessors.
- Account: The organization, subscription and settings covered by the evidence.
Approval should follow the data path, not the product logo.
For a deployment intended to keep processing local, verify that boundary too. Check whether telemetry, diagnostics, fallback services or optional integrations send content elsewhere. A “local” label is not sufficient evidence.
Contracts establish obligations; checks establish collection behavior
A configuration screen can show that a control is enabled in a particular account. It does not, by itself, establish the provider's obligations for every copy of submitted content. Conversely, a contractual restriction does not establish that an integration collects only the intended context.
Use both kinds of evidence:
| Question | Evidence to request | Accountable reviewer |
|---|---|---|
| What leaves the environment, and where does it go? | Integration documentation; data flow, endpoints and subprocessors; scoped check with dummy content | Engineering lead and security reviewer |
| What is retained, why, and for how long? | Applicable terms for content and derived records, including logs, support records and exceptions | Legal or procurement owner, with security review |
| Can content be used for training? | Binding terms for the exact service and account type; required opt-out settings | Legal owner and account administrator |
| What can be deleted, and when? | Deletion commitments, request procedure, backup treatment and retained-record exceptions | Legal owner and security reviewer |
| Can the configuration be maintained? | Settings record, administrator permissions and change-review procedure | Engineering tool owner |
The evidence need not promise zero retention or immediate deletion in every circumstance. It must be specific enough for the responsible owners to accept or reject the actual handling terms.
An unknown is material if its answer would change whether the proposed content is allowed. Resolve it before rollout, not afterward.
Copy this data-use approval record
Use one record per materially distinct workflow or deployment mode. Keep the scope and content decisions together, link the supporting evidence, and replace role labels with actual names.
The entries below carry the opening example into a copyable record. The content boundaries are recommended starting positions, not completed approvals.
Data-use approval record
- Tool, service and deployment mode: [Name the editor integration or repository-connected service being assessed.]
- Organization, account, subscription and integration version: [Record the exact configuration.]
- Intended task and repositories: [Identify selected-function assistance or repository indexing, and the repositories involved.]
- Coding-evaluation result: Selected-function suggestions passed the team's tests; repository indexing was not evaluated by those tests.
- Overall outcome: Hold the proposed private-repository connection while retention, training use and terms coverage remain unresolved.
- Evidence: [Link data-flow checks, applicable contracts and verified settings for this workflow.]
- Accepted conditions and unresolved questions: [Record handling limits, deletion terms and material gaps.]
- Named approvers: [Engineering, security and legal approvers, with names.]
- Decision date and review triggers: [Date.] Reopen review for a new repository connection or changes to deployment mode, account terms, context collection, processing destination or content class.
| Content | Outcome | Permitted content | Collection boundary | Required evidence | Named owner or approvers |
|---|---|---|---|---|---|
| Source code | Hold for proposed private indexing | Record allowed repositories, paths or selected functions | Specify manual submission versus automatic context collection or indexing | Classification, sharing authority and workflow-specific handling evidence | [Repository owner, security reviewer, legal owner] |
| Repository metadata | Hold until fields and handling are assessed | List allowed filenames, paths, commit messages, issue text and identity fields | Specify fields and collection methods; public source does not make associated metadata public | Submitted-field inventory and applicable handling evidence | [Tool owner, security reviewer, legal owner for contractual acceptance] |
| Secrets and credentials | Prohibit live secrets; record restricted evaluation scope or hold | Dummy credentials in isolated evaluations | Exclude live credentials; deny the affected workflow if exclusion cannot be enforced adequately | Exclusion verification and accidental-disclosure response procedure | [Security owner, engineering tool owner] |
| Production-derived examples | Hold customer-derived material pending specific approval | Prefer synthetic examples; identify any specifically approved material | Limit collection to the approved material | Provenance, sensitivity review, sharing authority and processing evidence; removing obvious identifiers alone is insufficient | [Data or service owner, security reviewer, legal/privacy owner] |
Use these outcome labels consistently:
- Approved: The stated content and workflow are allowed under recorded conditions.
- Restricted: Only a narrower, enforceable scope is allowed, such as a synthetic test repository.
- Hold: Material questions remain unresolved, or the accepted terms do not permit the intended use.
Restricted approval needs an enforceable boundary. “Avoid sensitive information” is inadequate when an integration can automatically collect repository context. If the boundary cannot be maintained, hold that workflow.
The restriction should follow the evidence, not the fact that a tool uses AI. A private-code workflow can be approved when its terms and verified configuration support the intended use and named owners accept responsibility.
Code-quality and release checks remain separate gates, with the engineering owner responsible for review and validation of resulting changes.
Passing coding tests does not expand permission to receive data.
Try a five-minute scope check
Choose one planned workflow and populate the same approval record. Start with the collection boundary: selected functions, automatic context or repository indexing. Add the evidence you have for destination, retention, training use and deletion, then mark the gaps.
If a gap would change permission for the proposed content, record a hold for that scope and name the person responsible for resolving it. This is triage, not a substitute for contractual review or technical verification.