AI coding assistants on agency software projects: policy and review

Reference article · 5 min read

Code assistants are now built into the editors, repositories, and platforms most development teams already use. Whether or not an agency has written a policy, some of the code produced for its systems, by staff developers or by a contractor's engineers, is being drafted with model assistance. The question is not whether to permit the tools but what conditions to attach and what evidence to require that those conditions were met.

Most published guidance on generative AI in government addresses staff use of chat tools or public-facing systems. Code assistants raise different concerns. They operate inside source repositories, they sit near credentials, and what they produce becomes a deliverable the agency owns and maintains for years.

Where the risk actually sits

The common worry, that the tool writes bad code, is the smallest part of it. The failure modes that matter are narrower.

Exposure. Source code, configuration, and sample data leave the agency environment as prompt context.
Provenance. A suggestion may closely reproduce code the model saw in training, along with that code's license terms.
Ownership. Rights in machine-generated material are less settled than rights in human-written work, which strains standard assignment clauses.
Plausible but wrong. Generated code often uses deprecated APIs, insecure defaults, or logic that is right in general and wrong for the agency's rules.
Volume. Assistants increase how much code is produced far more than they increase review capacity. Review becomes the bottleneck, and quality quietly drops.

Repository and data exposure

Learn what each tool transmits. Inline completion sends surrounding file content and some repository context. Agentic tools read across a repository, run commands, and may fetch outside material. Ask where that content is processed, how long it is retained, whether it trains models, and whether retention is off by default at your tier or only on request. Defaults change, so confirm current terms.

Managed accounts only. Assistants run under agency-controlled identities with single sign-on and logging, never personal accounts.
No production data in lower environments. Copies of real records in development and test are the most common way regulated data reaches a tool nobody assessed for it.
Decide repository by repository. Code for systems holding criminal justice, health, or student records deserves a documented decision before an assistant is enabled, and assistant logs may themselves be records.

License and provenance of generated code

Assistants are trained on large volumes of public code under varied licenses, including copyleft licenses that impose obligations on distributed derivative works. Enable the setting that suppresses suggestions matching public code where a tool offers one, and require vendors to do the same. Then treat dependencies as the larger exposure: an assistant will readily add a library, and license scanning with a software bill of materials catches an incompatible dependency more reliably than reading line by line.

Some tool vendors offer indemnification against intellectual property claims arising from their output, usually conditioned on particular settings and tiers. Read those conditions and confirm your teams operate inside them.

Ownership and deliverable clauses

Agency contracts normally assign all rights in the work product to the agency, language that assumes a human author. The U.S. Copyright Office has taken the position that copyright protection requires human authorship and that purely machine-generated material is not protectable. An assignment clause cannot convey rights that may not exist, so specify what you actually need.

Assignment of whatever rights do exist, plus a broad, perpetual, irrevocable license to use, modify, and have others modify the deliverable.
A warranty of non-infringement, with defense and indemnity obligations that survive acceptance.
Delivery of complete source, build scripts, configuration, and dependency manifests, so the agency can rebuild the system without the vendor.

Confirm exact language with counsel. State contract law varies, and the legal picture on generated works continues to develop.

Human review, testing, and secret handling

A named human is accountable for every merged change. A reviewer who cannot explain and modify the code should not approve it.

Review depth stays constant. If output rises, either staffing rises or the merge rate falls.
Gates run on every branch. Static analysis, dependency scanning, and secret scanning belong in the pipeline, not on a pre-release checklist.
Secrets never enter prompts. Keys and connection strings live in a secret manager. Anything appearing in a prompt, a log, or a commit is treated as compromised and rotated.
Watch familiar defects. Hardcoded credentials, disabled certificate verification, permissive cross-origin settings, and string-built SQL queries show up regularly.
Check the tests too. Generated tests often assert what the code does rather than what the requirement says. Trace acceptance tests back to requirements.

What to ask vendors and what to require

A blanket prohibition is hard to verify and pushes use out of sight. Disclosure and controls work better.

Which code assistants do your engineers use on this work, at which tier, and under whose accounts?
Does agency code or data leave your development environment, and where is it processed and retained?
Are public code matching filters and training opt-outs enabled, and can you show the configuration?
Who reviews assistant-generated code, and what is your merge policy?
What indemnification do you carry for intellectual property claims on delivered code?

Require in the contract: disclosure of the tools in use and notice before adding others, a prohibition on sending agency data to unapproved services, an attestation at each delivery that all delivered code received human review, a software bill of materials, and flow-down of these terms to subcontractors. Before writing an agency-wide rule, ask your own developers what they already use, then pilot the policy on one project.

HQT builds and modernizes software for state and local government agencies and works with agency teams on development standards and code review practices.

Frequently asked questions

Should our agency ban AI coding assistants on government software projects?

A ban is difficult to verify and tends to move use out of sight rather than stop it. Most agencies get better results by approving specific tools configured to meet their data handling rules, prohibiting others, and requiring disclosure from contractors. Pair that with unchanged human review and testing requirements so the approval does not weaken existing controls.

Who owns code that a vendor wrote with an AI coding assistant?

Your contract's assignment clause still governs the work product, but rights in purely machine-generated material are less settled than rights in human-written code, and the U.S. Copyright Office has taken the position that copyright protection requires human authorship. The practical protection is to require assignment of whatever rights exist plus a broad perpetual license to use and modify the deliverable, a non-infringement warranty with indemnity, and delivery of complete source and build materials. Confirm specific language with your counsel, since this area continues to develop.

Should we require vendors to disclose whether they used AI to write our code?

Yes, and it is easier to enforce as a standing contract term than as a question asked once during evaluation. Ask which tools are used, at what subscription tier, under whose accounts, whether agency code leaves the vendor environment, and who performs human review before merge. Add a requirement for notice before the vendor adds a new tool, and flow the same terms down to subcontractors.

Can an AI coding assistant create open source license problems for an agency system?

It can, in two ways. A suggestion may closely reproduce code the model saw in training along with that code's license obligations, and an assistant may add a dependency whose license conflicts with how the agency plans to use or distribute the software. Enable public code matching filters where the tool offers them, and require a software bill of materials with automated license scanning, which catches the dependency problem more reliably than manual review.

What should change in our code review process when developers use assistants?

Keep review depth constant even though more code arrives, which usually means limiting pull request size rather than relaxing scrutiny. Require a named human reviewer who can explain and modify the code, and run static analysis, dependency scanning, and secret scanning automatically on every branch. Also review the generated tests, since they often assert what the code does rather than what the requirement says.