AI-Generated Code Provenance: A Practical Review Policy for Java and

AI-generated code provenance is useful when it records review-relevant facts instead of acting as a quality label. A pull request still needs to be judged on behavior, security, maintainability, testing, licensing obligations, and ownership. Provenance gives reviewers context about where to look more closely, such as generated logic, a new dependency recommendation, or a broad mechanical transformation.

For Java and React teams, the goal can stay deliberately modest: preserve human accountability while making material AI-assisted changes easier to review and trace later. A short pull-request disclosure, structured Git metadata where needed, ordinary CI gates, and careful dependency review provide a practical foundation.

Start With Accountability, Not an AI Badge

An AI-assisted label cannot prove that a change is correct, secure, or adequately tested. It also does not make a change inherently unsafe. The meaningful question is whether the human submitting the change understands it, validates it, and accepts responsibility for its effects.

The Linux kernel documentation provides a useful example of this model. Its policy for AI-assisted contributions calls for standardized commit metadata while keeping responsibility for correctness, licensing, and contribution obligations with the human contributor. It also states that an AI system cannot provide a Developer Certificate of Origin sign-off because that declaration must come from a person. See the Linux kernel documentation on AI coding assistants.

Application teams can apply the same principle without adopting the kernel’s exact workflow. Treat provenance as contextual evidence. It should help a reviewer ask useful questions: Did a React component add a package that needs verification? Did a Java implementation rely on assumptions the author has tested? Does a large generated refactor have enough evidence to establish that its intended scope is complete? The record should never shift responsibility from a developer to a tool.

A Lightweight Policy for Material Assistance

A useful policy covers assistance that meaningfully shaped the delivered change without requiring developers to document every autocomplete suggestion. The policy should be short enough to follow consistently and specific enough to improve review decisions.

Disclose material assistance

Require disclosure when an AI tool produced or substantially transformed code, tests, infrastructure configuration, database queries, technical documentation, security-sensitive logic, or a dependency recommendation that is included in the change.

Do not require disclosure for a minor completion that the author immediately rewrote, routine syntax assistance, or a tool used only to explain existing code. Recording every interaction creates noise and can turn a review signal into a checkbox exercise.

Record review evidence, not prompt transcripts

Reviewers rarely need an entire conversation with a coding assistant. They need enough information to understand the affected area, the kind of assistance used, whether dependencies changed, and how the author validated the result.

For sensitive changes, keep any additional evidence in the pull request or an approved internal record rather than adding prompts to Git history. Avoid placing secrets, customer data, or proprietary context into provenance fields. The objective is better auditability, not a new channel for exposing information.

State human responsibility explicitly

When material assistance is disclosed, the author should confirm that they reviewed the affected code and accept responsibility for it. This establishes a practical standard: generated code should not be submitted until its author can explain its behavior, important failure paths, validation, and dependency choices.

Keep ordinary quality gates in place

AI-assisted changes should move through the same branch protections, peer review, testing, static analysis, secret scanning, and dependency controls as other changes. The difference is targeted reviewer attention for risks associated with generated output, especially suggested dependencies and security-sensitive boilerplate.

OpenSSF guidance on AI code assistant instructions emphasizes developer verification, automated checks, and peer review rather than blind reliance on generated output. That layered approach is more useful than treating an AI label as evidence of quality. See OpenSSF Best Practices.

Give Reviewers Evidence That Matches the Risk

Use a small evidence model that scales with the change. The author provides concise context first; reviewers request deeper evidence only when the implementation warrants it.

Change type	Minimum evidence	Reviewer focus
Small Java or React implementation change	AI assistance disclosed, affected area identified, tests run	Behavior, edge cases, ownership
New dependency or build configuration	Dependency rationale, intended source verified, dependency file and lockfile reviewed where applicable	Existence, provenance, versioning, supply-chain exposure
Authentication, authorization, cryptography, payments, or data handling	Disclosure, relevant security considerations, tests and scans	Assumptions, unsafe defaults, error handling
Large refactor or generated migration	Scope summary, validation plan, representative test evidence	Completeness, regressions, unintended edits

This avoids an unhelpful split between AI-written and human-written code. A small generated utility can be lower risk than a manually authored authorization change. The evidence required should follow the impact of the change, not the identity of the authoring tool.

Add a Pull Request Disclosure

Add a compact section to the existing pull-request template. It can be skipped for changes with no material assistance, but it should be completed when the policy threshold is met.

## AI assistance and review evidence

- [ ] No material AI assistance was used.
- [ ] AI assistance materially influenced this change.

If AI-assisted:
- Affected areas:
- Assistance type: implementation / tests / refactor / docs / dependency suggestion
- New or changed dependencies:
- Validation performed:
- Author confirmation: I reviewed the affected code and accept responsibility for it.

Do not require prompt text by default. Ask the author to explain the engineering decision that matters to the patch. For example, a React author could identify that an assistant drafted a custom hook and describe the tests used to validate its behavior. A Java author could identify AI assistance on a serialization configuration and describe the scenarios covered by tests.

The template is not a substitute for review. It gives reviewers a starting point and creates a consistent place to capture evidence that might otherwise be scattered across comments, commits, and chat.

Use Commit Trailers When a Durable Record Is Needed

Pull-request text is useful during review, but some teams need provenance that remains queryable after a merge or squash workflow. For those repositories, use a structured Git trailer, such as:

Assisted-by: coding-agent:model-name [implementation, tests]
AI-Review: author-reviewed

Git supports structured commit-message trailers and provides git interpret-trailers for adding and parsing them. The exact field names are a team convention. Consistent syntax is more valuable than a large metadata schema.

The Linux kernel policy uses an Assisted-by: trailer for its own contribution workflow. A Java or React team can adopt a comparable convention when durable disclosure is necessary, while keeping the fields limited to information reviewers can use.

Reserve trailers for material assistance, high-risk repositories, or environments with an audit need. Requiring them for every trivial change creates false precision and makes commit history less useful. CI can validate required trailer structure, but it cannot reliably determine whether an author used an AI tool.

Make Dependency Review the Extra Gate

Dependency suggestions deserve particular scrutiny. A study of code-generating language models examined package hallucinations across evaluated models and found nonexistent package recommendations in JavaScript and Python. The paper describes how such recommendations can create an opportunity for attackers to register plausible package names, sometimes called slopsquatting. See We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code-Generating LLMs.

For React applications, require a reviewer to verify a new npm package through the registry and the package’s relevant project information. Confirm that the imported package matches the dependency and lockfile entry being reviewed. Review the need for the package rather than accepting it merely because its name appears plausible.

For Java applications, apply the same discipline to Maven or Gradle coordinates, repository sources, transitive dependencies, and resolved versions. A familiar-looking artifact name is not evidence that it is the intended library or that it is appropriate for the project.

The OWASP Top 10 for Large Language Model Applications identifies supply-chain vulnerabilities and excessive agency among risks in generative-AI applications. For a delivery workflow, the practical response is to retain human approval for dependency additions, review resolved versions, and continue using dependency and vulnerability scanning controls.

Use CI to Verify Controls, Not Tool Usage

CI should verify policy mechanics and technical outcomes. It should not attempt surveillance or make claims it cannot establish.

• Validate provenance trailer syntax in repositories that require trailers.
• Require completion of the pull-request disclosure for designated high-risk paths.
• Run the repository’s existing unit, integration, linting, type-checking, build, and static-analysis jobs.
• Detect dependency manifest and lockfile changes, then require dependency-review approval.
• Run secret scanning and dependency vulnerability checks for all changes, regardless of how they were authored.

For React repositories, CI should reflect the application’s actual conventions, such as TypeScript checks where used, component or integration tests, linting, and production builds. For Java repositories, use the project’s applicable compilation, unit testing, integration testing, static analysis, and dependency resolution checks. A generic provenance job cannot compensate for missing application-specific validation.

A Practical Review Conversation

When a pull request declares material AI assistance, reviewers can use four questions:

1. Scope: Which parts of the patch were materially generated or transformed?
2. Understanding: Can the author explain the behavior and relevant tradeoffs?
3. Validation: Which tests, analysis, or manual checks support the intended behavior?
4. Supply chain: Did the change add or modify a dependency, artifact source, or generated asset requiring separate verification?

These questions are tool-neutral. They remain useful as models and coding workflows change, and they keep the review centered on accountable engineering rather than the presence of an AI label.

Implementation Checklist

• Define material AI assistance in one short policy paragraph.
• Add a disclosure section to pull-request templates.
• Choose one structured commit trailer for repositories that need durable provenance.
• Document categories that require deeper evidence, including sensitive data flows and dependencies.
• Require dependency review for changed npm, Maven, Gradle, and applicable lockfile entries.
• Keep tests, static analysis, secret scanning, and dependency checks mandatory for every change.
• Train reviewers to ask about scope, understanding, validation, and supply-chain evidence.
• Review the policy after several iterations and remove fields that do not improve review decisions.

When Formal Supply-Chain Metadata Is Justified

Most product teams do not need a model-level evidence archive for every commit. Organizations with contractual, regulatory, procurement, or supply-chain reporting requirements may need more structured artifact relationships. SPDX provides software supply-chain standards work, including material related to AI systems, and is a useful starting point for teams evaluating a more formal approach. See SPDX.

That is a different maturity level from a pull-request template and commit trailer. Start with reviewable engineering evidence. Add formal metadata only when an actual audit, customer, or operational requirement justifies its cost.

FAQ

Should every AI-assisted commit carry a label?

No. Require disclosure when assistance materially influenced the delivered change. Tracking trivial autocomplete creates noise without improving review quality.

Does AI-generated code automatically require another reviewer?

No. Add review expertise based on risk: security review for sensitive flows, dependency review for new packages, and domain-owner review for complex business logic.

Can CI prove that a developer used AI?

No. CI can validate required metadata and technical controls. It should focus on tests, dependency changes, evidence, and policy compliance rather than unverifiable detection.

What is the first policy change to make?

Add a concise material-assistance section to the pull-request template, then require dependency review for any new package or artifact introduced in an AI-assisted change.

Sources

• Linux Kernel Documentation: AI Coding Assistants Policy
• OpenSSF Best Practices
• We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code-Generating LLMs
• Git Documentation: git-interpret-trailers
• OWASP Top 10 for Large Language Model Applications
• SPDX

Editorial note: AI assisted with research and drafting. Sources were selected for verification.