Protect company data in AI coding

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 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.