Say that AI generated suggestions are held to the same controls as any other change: code review, dependency review, automated checks on the pull request and a named owner. Describe which tools are approved and what data they may see, and avoid claiming that AI tools are risk free.
Why customers ask
Assistants can suggest a package to solve a problem, and the suggestion may be an unneeded library, an old version or a name that does not match a real project. That makes the dependency question part of the AI question. The control is the same as before, applied consistently.
Questions to settle internally first
- Which AI coding tools are approved, and who decided?
- What code or data may they access?
- Do suggested dependencies go through the same review as manual ones?
- Are pull requests marked or traceable when AI assistance was used, if your policy requires it?
- Does the pipeline block unreviewed new packages regardless of origin?
If any answer is "we have not decided", say a policy is in progress.
The controls that carry over
NIST SP 800-218 practices on reviewing third party components (PW.4.1), verifying they meet your requirements (PW.4.4) and reviewing code (PW.7) do not depend on who typed the change. That is the useful framing: the author of a change does not change the checks.
| Control | Applies to AI suggested changes how |
|---|---|
| Dependency review | New package needs the same justification |
| License check | Same allowed list |
| Vulnerability match | Same advisory checks on the pull request |
| Code review | Same reviewer standards |
| Provenance and lockfile | Same install rules |
What to avoid claiming
- That AI output is "verified" by default.
- That you block all AI usage unless you actually can.
- Specific detection abilities you do not operate.
Reply template
Approved AI coding tools are listed in our internal policy. Suggested code and dependencies go through the same review and automated checks as any change, including dependency review, license rules and vulnerability matching on pull requests. Access to code and data is limited by policy.
Related reading: can AI generated code be trusted.
Evidence that is easy to produce
A customer will likely ask to see something. Useful artifacts include the approved tools list with its review date, the policy paragraph on data access and a pull request that shows a suggested dependency being questioned in review. If your pipeline blocks unreviewed new packages, an export of that rule shows the control works regardless of authorship.
Keep the tone factual. Customers do not expect you to ban assistants. They expect you to know where they are used and to apply the same checks to their output as you apply to everything else that reaches production.
Quick check
Do we need a separate policy for AI assistants?
A short section within your secure development policy is usually enough, as long as it names approved tools and data limits.
Should AI tools be allowed to add dependencies directly?
If they can, make sure the pipeline treats the change as unreviewed until a person approves it.
Sources
Last reviewed: 19 October 2026.
