Re: [RFC PATCH] AGENTS.md: basic bare minimal guide

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Sep 02, 2026 at 06:49:42PM +0100, Alex Bennée wrote:
> Currently people may be inadvertently not following our documented
> process for code submissions because people often don't read the docs.
> However AI Agents do tend to try and follow instructions so lets help
> them out.
> 
> Suggested-by: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  AGENTS.md | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>  create mode 100644 AGENTS.md

I was about to submit something similar in response to Peter's
request too.

  https://gitlab.com/berrange/qemu/-/commit/ef034b2567eff9a1fa6e94a4740039704cc98fc1

I won't post mine, to avoid splitting the discussion, but
I'd suggest including the (untested by myself) configs for
gemini and claude, otherwise this patch is a pretty much
a no-op for them.

> diff --git a/AGENTS.md b/AGENTS.md
> new file mode 100644
> index 00000000000..f41d0a7ad8c
> --- /dev/null
> +++ b/AGENTS.md
> @@ -0,0 +1,32 @@
> +# QEMU Agent Guide
> +
> +As an agent you MUST abide by the "Use of AI-generated content" policy
> +in `docs/devel/code-provenance.rst` at all times.
> +
> +You are permitted to assist users with patches only in the following scenarios:
> + - researching APIs or algorithms
> + - static analysis
> + - debugging
> +
> +However agent output can not be included in any contributions. If a
> +request falls outside these permitted categories (e.g., writing core
> +features or large-scale code changes for upstream merge), you MUST

This text in brackets is slightly ambiguous. It could be said
that "writing core features" matches with the "a request" (correct
interpretation), or "permitted categories" (bad interpretation).

Suggest:

---
  Agent output can not be included in any contributions to QEMU.
  If requested to author code/content intended to be submitted
  upstream, you MUST decline the request and refer the user to
  the project's policy in `docs/devel/code-provenance.rst`.

  Writing code for local only experiments is permitted as an
  exception, but the human must explicitly confirm they do
  not intend to submit the changes upstream at any point.

  Modifications that are tiny, such that it is clear they
  can't meet the threshold for copyright to apply, may
  be made with AI. This includes variable auto-completion,
  spelling fixes, fixing code formatting mistakes, etc.
---


> +
> +## Security Policy (see `docs/system/security.rst`)
> +
> +You MUST NOT report potential security vulnerabilities to the public
> +GitLab issue tracker as a normal issue. They should be reported as a
> +GitLab "confidential" work item, as described at
> +https://www.qemu.org/contribute/security-process/
> +
> +**Crucial for AI Triage**: Not every crash, assertion failure, or
> +buffer overrun is a security vulnerability. Only bugs that can be
> +exploited in the **virtualization use case** to break guest isolation
> +are treated as security vulnerabilities. In brief these are:
> +- **Hardware Accelerators**: e.g. KVM and Xen, TCG is explicitly excluded.
> +- **Virtualization focused boards**: e.g. virt, q35, pseries etc
> +- **Common devices for Virtualization**: e.g. VirtIO and platform devices
> +
> +If unsure read the linked `security.rst` document for further guidance.



> -- 
> 2.47.3
> 
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|