feat: Make our stance regarding AI usage more explicit. (#6621)

* feat: Make our stance regarding AI usage more explicit.

Signed-off-by: Jean-Philippe Evrard <jean-philippe.evrard+rochepub@external.roche.com>

* Improve based on @alekc comments

Signed-off-by: Jean-Philippe Evrard <jean-philippe.evrard+rochepub@external.roche.com>

---------

Signed-off-by: Jean-Philippe Evrard <jean-philippe.evrard+rochepub@external.roche.com>

.github/pull_request_template.md

@@ -32,6 +32,22 @@ Where `scope` is _optionally_ one of:
 - security
 - templating
 
+## AI Assistance disclosure
+
+Did you use an script, LLM, or AI assisted development tool for this contribution?
+
+AI assistance used: Yes / No
+
+If yes provide details:
+
+Tool(s) used:
+
+Purpose of assistance:
+
+Parts of the contribution affected:
+
+Human validation performed:
+
 ## Checklist
 
 - [ ] I have read the [contribution guidelines](https://external-secrets.io/latest/contributing/process/#submitting-a-pull-request)
@@ -39,3 +55,5 @@ Where `scope` is _optionally_ one of:
 - [ ] My changes have reasonable test coverage
 - [ ] All tests pass with `make test`
 - [ ] I ensured my PR is ready for review with `make reviewable`
+- [ ] I confirm that I understand the submitted changes and can explain them without relying on an AI tool.
+- [ ] I have tested my changes on a live environment to confirm they are working

AGENTS.md

@@ -6,6 +6,8 @@ Kubernetes operator that synchronizes secrets from external providers (AWS Secre
 
 Use `make` targets — refer to the Makefile for available commands. Do not run `go test`, `golangci-lint`, or `helm` directly.
 
+You must run `make test && make check-diff` before the PR is ready. (See also section Non-Obvious patterns for more explanations about the tests)
+
 ## Project Layout
 
 Single binary built from `main.go`. The **controller** reconciles ExternalSecrets into K8s Secrets. The **webhook** (validates and defaults CRDs) and **certcontroller** (manages webhook TLS) are subcommands registered via `rootCmd.AddCommand()`.
@@ -23,6 +25,7 @@ Multi-module repo: `apis/`, `runtime/`, `e2e/`, and each `providers/v1/*/` have
 - If you discover a non-obvious pattern while implementing, add it here before the PR is merged. Keep entries general — applicable across the codebase, not specific to one provider or feature.
 - Never edit `zz_generated.*` files by hand. They are owned by controller-gen. Modify the source types and run `make generate` (included in `make reviewable`).
 - After everything is committed - **ALWAYS RUN `make check-diff`** - this is the first step where PRs fall apart that LLMs forget - there are a lot of generated code outside of the main `make reviewable` spec like helm chart tests, docs, etc.
+- 
 
 ## Adding a Provider
 
@@ -221,3 +224,51 @@ pattern, but expect to be the first.
 - Docs page + snippets.
 - mkdocs nav entry.
 - After adding the module to `go.work`, run `go work use` to reconcile the `go` directive version.
+
+## Allowed agent actions
+
+Agents may:
+
+- inspect the repository,
+- explain code,
+- propose changes,
+- edit local files,
+- write tests,
+- update documentation,
+- run checks,
+- prepare a local diff for human review,
+- ...
+
+in order to assist humans.
+
+## Blocked actions
+
+Agents must not:
+
+- create pull requests,
+- push branches,
+- publish releases,
+- upload packages,
+- change repository settings,
+- change permissions,
+- rotate credentials,
+- modify secrets,
+- perform external write actions.
+
+If asked to perform a blocked action, do not perform it. Instead, create a local file named AGENT_BLOCKED_ACTION.md containing:
+
+1. the requested action,
+2. why the action is blocked,
+3. the local work that was completed, if any,
+4. the recommended manual steps a human contributor should take next.
+
+## Work verification checklist
+
+Before presenting work as complete, verify:
+
+- [ ] the intent is documented,
+- [ ] the diff is minimal and surgical (must not touch adjacent comments or code unrelated to the work),
+- [ ] the relevant tests were run (see build and test section),
+- [ ] the documentation was updated.
+
+If validation could not be completed, state it explicitly and explain why.

docs/contributing/llm-policy.md

@@ -9,3 +9,76 @@ If you use an LLM to help with your contribution, that's fine. Just make sure yo
 The same goes for issues. Don't submit LLM-generated bug reports or feature requests that are verbose, generic, and obviously haven't been thought through. If an AI helped you articulate something, great, but the issue should still sound like it came from someone who actually encountered a problem or has a real use case.
 
 We value contributions from humans who understand what they're submitting, even if they had some algorithmic assistance along the way. The goal is quality and genuine engagement with the project, not quantity of AI-generated content.
+
+## Liability
+
+However, contributors remain fully responsible for anything they submit. Do not submit generated content that you have not reviewed, understood, adapted to this project, and verified.
+
+## Disclosure Required
+
+All AI assistance must be disclosed in issues, discussions, and pull requests.
+
+For pull requests, include:
+
+* the tool or tools used,
+* what the tool helped with,
+* which parts were generated, edited, or reviewed with AI assistance,
+* and what validation you performed yourself.
+
+For issues and discussions, disclose AI assistance if an LLM helped draft, structure, summarize, or rewrite the content.
+
+## Human Ownership
+
+You must understand your contribution well enough to explain it without using an AI tool.
+
+For code changes, you should be able to explain:
+
+* what changed,
+* why the change is needed,
+* how it interacts with nearby code,
+* what alternatives you considered,
+* and how you verified correctness.
+
+If you cannot explain the change, do not submit it.
+
+## Quality Expectations
+
+LLM-assisted contributions must follow the same quality bar as any other contribution.
+
+Do not submit:
+
+* generic or speculative issues that do not come from a real use case,
+* verbose bug reports that obscure the actual problem,
+* boilerplate comments that do not add useful information,
+* code that ignores existing project patterns,
+* tests that assert implementation details without proving behavior,
+* documentation that restates obvious facts,
+* or changes that shift basic validation work onto maintainers.
+
+Before submitting, check the existing codebase conventions (check other providers for example), run our tests (we documented them in `AGENTS.md`).
+
+## Issues and Discussions
+
+AI-assisted issues and discussions are allowed, but **they must be human-reviewed and edited if needed before submission**.
+
+A good issue should describe a real bug, use case, regression, limitation, or design problem, with the code base version and a full context.
+The context is required for maintainers to evaluate the issue without having to reconstruct the problem from generic AI-generated text.
+
+This is also necessary to avoid the [XY Problem](https://en.wikipedia.org/wiki/XY_problem).
+
+## Enforcement
+
+Maintainers may close issues, discussions, or pull requests that appear to be unreviewed AI-generated output, omit required AI disclosure, lies about AI disclosure, ignore project conventions, or create unnecessary review burden.
+
+Violations may result in a temporary contribution ban, documented in our code of conduct document.
+
+Examples of violations that may lead to a temporary ban include:
+
+* repeatedly submitting undisclosed AI-generated content,
+* submitting large unreviewed AI-generated pull requests,
+* using autonomous agents to open issues or pull requests without human review,
+* resubmitting closed AI-generated content without addressing maintainer feedback,
+* or misrepresenting generated work as personally authored and verified.
+
+The goal of enforcement is to protect maintainer time, project quality, and respect of the spirit of the DCO. It is not meant to prohibit responsible AI use.
+