Policy for Code and Developers

AI coding assistants are the most widely adopted category in most technical organisations and the one general policy handles worst.

The controls in “Policy for Code and Developers” only remain useful when someone owns the reviews, exceptions and follow-up work. An organisation evaluating the full explanation can attach time and responsibility to those recurring governance tasks, but the platform should support the policy rather than decide whether an AI use case is acceptable.

For an independent benchmark, compare the local approach with OWASP GenAI Security Project; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

Why it is different

The input is source code, which may be commercially sensitive, licensed, or a client's.

The output enters a product, with a licensing question attached.

Adoption is near-universal among developers and happened before anybody wrote a policy.

And the productivity effect is real enough that withdrawal has a visible cost, which changes the negotiation.

The input question

Does the assistant send surrounding code to the provider, and how much?

Some operate locally, some send context sent with each requests of the open file and related files, some index the whole repository.

This varies by product and by configuration and is worth establishing specifically.

Client code under contract is the sharp case — the subprocessor point in the regulated-data note applies directly.

The output question

General orientation, not legal advice; the position is unsettled and being litigated.

Generated code may resemble training material, and the licensing consequences are genuinely unclear.

Some providers offer indemnities and filtering for near-matches; the scope varies.

For most internal software the practical risk is low. For distributed products and anything with open-source licence obligations it deserves a real look.

The review question

Generated code that nobody understands entering a codebase is a maintenance problem before it is a legal one.

The rule worth having: the person committing it is accountable for it, as they always were.

Which is not a new principle and is worth restating, because "the assistant wrote it" has appeared in incident reviews.

Secrets in context

Configuration files, connection strings and test credentials sit in repositories and get sent as context.

This is the credential prohibition arriving by a route nobody intended.

Check what your assistant's context sent with each request includes, and keep secrets out of the repository, which is good practice regardless.

Local models

Running a model on the developer's machine removes the data question entirely.

Costs resource and quality, gains simplicity.

Worth offering for work on the most sensitive codebases, as a middle option between the approved cloud assistant and nothing.

Writing the rule

Approved assistant, configured with a known context scope.

Client code only where the client agreement permits it.

Committer is accountable for what they commit.

Secrets never in the repository.

Four lines, and developers will follow them because they are specific.

What to check

Do you know what context your coding assistant sends?

Does any client agreement prohibit it?

Are secrets present in repositories that get indexed?

And is there a local option for the most sensitive work?

The point

Coding assistants send surrounding code as context, which means secrets in the repository leave with it.

Check what your context sent with each request includes.

Underlying all of this

Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.

The recurring pattern

The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.