diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8a8609051e..d40cd581b9 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -18,6 +18,7 @@ information regarding copyright ownership.
 1. [Access to source code](#access)
 1. [Reporting bugs](#bugs)
 1. [Contributing code](#contrib)
+1. [Generated code](#generated-code)
 
 ### Introduction
 
@@ -188,6 +189,101 @@ automated testing and cannot merge new code without adequate test coverage.
 Please see [the "Testing" section of doc/dev/dev.md](doc/dev/dev.md#testing)
 for more information.
 
+### <a name="generated-code"></a>Guidelines for Tool-Generated Content
+
+#### Purpose
+
+BIND 9 contributors have long used tooling to assist in development.
+These tools can increase the volume and velocity of contributions.  At
+the same time, reviewer and maintainer bandwidth is a scarce resource,
+and the stability of DNS software is critical infrastructure.
+Understanding which portions of a contribution come from humans versus
+tools is helpful to maintain those resources, assess risk, and keep
+BIND 9 development healthy.
+
+The goal here is to clarify community expectations around tools,
+particularly LLMs (Large Language Models) and generative AI.  This
+lets everyone become more productive while maintaining high degrees of
+trust between submitters and reviewers.
+
+#### Out of Scope
+
+These guidelines do not apply to tools that make trivial tweaks to
+preexisting content or verify adherence to style guides.  Nor do they
+pertain to AI tooling that helps with menial tasks.  Some examples:
+
+ - Spelling and grammar fix-ups, like rephrasing documentation to the
+   imperative voice.
+ - Typing aids like IDE identifier completion, common boilerplate, or
+   trivial pattern completion.
+ - Purely mechanical transformations like variable renaming across a
+   scope.
+ - Reformatting using the standard BIND 9 clang-format configuration
+   or black (for Python system tests).
+
+Even if your tool use is out of scope, you should still always
+consider if it would assist the review of your contribution if the
+reviewer knows about the tool that you used.
+
+#### In Scope
+
+These guidelines apply when a meaningful amount of content in a BIND 9
+contribution (code, documentation, or tests) was not written by a
+person contributing the patch or merge request, but was instead
+created by a tool.
+
+Detection of a problem and testing the fix for it is also part of the
+development process; if a tool was used to find a problem addressed by
+a change (e.g., a fuzzer or static analyzer), that should be noted in
+the commit message or MR description.  This not only gives credit where
+it is due, it also helps fellow developers find out about these tools.
+
+Some examples:
+
+ - Complex semantic patches generated by Coccinelle scripts.
+ - A chatbot or AI assistant generated a new function in your Merge
+   Request to handle a specific DNS RR type.
+ - A .c file or system test in the MR was originally generated by a
+   coding assistant but cleaned up by hand.
+ - The commit message or MR description was generated by handing the
+   diff to a generative AI tool.
+ - Documentation or comments were translated from another language
+   using an automated tool.
+
+If in doubt, choose transparency and assume these guidelines apply to
+your contribution.
+
+#### Guidelines
+
+You are responsible for the code you submit, regardless of how it was generated.
+When opening a Merge Request, be transparent about the origin of content in the
+MR description and commit messages.  You can be more transparent by adding
+information like this:
+
+ - What tools were used?
+ - The input to the tools you used, like the Coccinelle source script
+   or specific configuration.
+ - If code was largely generated from a single or short set of
+   prompts, include those prompts.  For longer sessions, include a
+   summary of the prompts and the nature of the resulting assistance.
+ - Which portions of the content were affected by that tool?
+ - How is the submission tested? (e.g., "I used tool X to generate a
+   system test case that triggers the bug.")
+
+As with all contributions, BIND 9 maintainers have discretion to
+choose how they handle the contribution.  For example, they might:
+
+ - Treat it just like any other contribution.
+ - Reject it outright if the provenance is unclear or the code quality
+   is low.
+ - Treat the contribution specially, such as reviewing with extra
+   scrutiny regarding memory safety or RFC compliance.
+ - Suggest a better prompt or approach instead of suggesting specific
+   code changes.
+ - Ask the submitter to explain in more detail about the contribution
+   to ensure the submitter fully understands the DNS logic or internal
+   BIND 9 architecture implemented by the tool.
+
 #### Thanks
 
 Thank you for your interest in contributing to the ongoing development