Add AI Contribution Policy for OpenSSF Technical Initiatives

[justaugustus]

Summary

• Introduces a comprehensive AI contribution policy for all OpenSSF Technical Initiatives, covering AI-assisted and AI-autonomous contributions, disclosure expectations, maintainer review practices, and repository-level agent configuration
• Establishes a permissive-by-default stance with clear accountability: five guiding principles, contributor responsibility framework (adapted from ASF guidance), and default prohibition on fully autonomous AI contributions
• Adds an OpenSSF-specific Security Considerations section addressing AI-generated code risks, with references to the BEST WG and AI/ML Security WG
• Provides governance mechanisms: TI-level exceptions via the TAC Decision Process, AGENTS.md adoption guidance, and annual review cadence with trigger-based interim reviews

Decision Type

Major — Cross-foundation policy change per the TAC Decision Process

• 15 business day review period
• 7 TAC approvers required

Key References

• Kubernetes contributor guide: pull requests
• ASF Generative Tooling Guidance
• RedMonk 2026 AI Policy Landscape in Open Source
• OpenSSF BEST WG: Security-Focused Guide for AI Code Assistant Instructions
• AGENTS.md specification

Review Suggestions

• TAC members review for completeness and alignment with OpenSSF governance
• AI/ML Security WG and BEST WG leads review for consistency with their published guidance
• Verify all external links resolve correctly
• Present at TAC meeting for discussion before vote closes

Co-Authored-By: Claude noreply@anthropic.com

[justaugustus]

@SecurityCRob — as promised, here's a starting point for the OpenSSF AI policy.

Tagging in the leads of relevant areas for review:

• AI/ML: @mihaimaruseac @camaleon2016
• BEST: @balteravishay @gkunz

cc: @ossf/tac

[lehors]

It would make sense to reference the Linux Foundation's Generative AI Policy:
https://www.linuxfoundation.org/legal/generative-ai

Even though I think its rule #2 represents a real challenge with many of the existing tools available today:

If any pre-existing copyrighted materials (including pre-existing open source code) authored or owned by third parties are included in the AI tool’s output, prior to contributing such output to the project, the Contributor should confirm that they have have permission from the third party owners–such as the form of an open source license or public domain declaration that complies with the project’s licensing policies–to use and modify such pre-existing materials and contribute them to the project. Additionally, the contributor should provide notice and attribution of such third party rights, along with information about the applicable license terms, with their contribution.

[TracyRagan]

This is a thoughtful and timely policy direction, and establishing a consistent foundation-wide stance on AI-assisted contributions makes sense given how quickly agent-supported development is evolving.

And as I mentioned on our call, there are a few practical concerns from the perspective of smaller or resource-constrained Technical Initiatives. The default prohibition on fully autonomous AI contributions may create friction for projects already relying on automation (e.g., dependency update bots or remediation workflows), especially as the boundary between “automation” and “autonomy” is still evolving. Clarifying that distinction would help maintainers apply the policy consistently.

Disclosure expectations and additional review considerations may also introduce extra overhead for already bandwidth-limited maintainer teams. Similarly, guidance around adopting AGENTS.md is forward-looking, but the ecosystem around it is still emerging and may be difficult for some projects to operationalize immediately.

It may help to position this policy clearly as guardrails with flexibility at the TI level, and to ensure the TAC exception pathway is lightweight enough to support legitimate security automation use cases as agent-driven workflows mature.

[arewm]

I don't know where the best place to include this is, but DCO signoff should NOT be done by an agent. These should only be done by a human which may be orchestrating the agent.

[justaugustus]

Hmmm... I'm not sure I agree here, but I also don't have a fully-formed opinion here just yet.

If we accept the framing of the policy (that AI is a tool in a contributor's toolbelt, just like any other), then what is the material difference between a human running git commit --signoff and an agent that a human has guided doing the same?

The real risk is an agent signing off without the human's meaningful involvement — but that scenario is already prohibited: autonomous contributions are not accepted by default, and contributors must understand and be able to explain every change they submit. If you can't explain the change, you shouldn't be certifying you have the right to submit it.

Open to debate here; this is just my initial take based on the current iteration of this policy and the DCO itself.

[arewm]

NOTE: This comment is from the perspective of commits. The discussion of human involvement is important for other contributions like comments/issues but it is not as easy to have a clear signal.

I accept that AI is just a tool, but it is a tool that provides new capabilities. With most other tools previously, the tools may have just informed the direction of work for humans to implement or at a maximum, the humans running them needed to verify the output that may have been generated. With LLM based tooling, however, it is easy to not review the changes at all.

I know that this document is worded in terms of meaningful human involvement

If you can't explain the change, you shouldn't be certifying you have the right to submit it.

This seems to pair well with the terminology from the DCO

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

What is not explicitly clear and is therefore up to interpretation is what a minimum human involvement is. If I have a well documented feature definition to constrain a LLM model producing a code change, is that meaningful involvement? I suspect that it isn't. If I use do that same process but I review the output for adherence/conformance to the spec, is the human involvement now meaningful enough? Do you have to iterate back and forth with an LLM as a human for involvement to become meaningful?

Just claiming that a human can explain the change is a much lower bar than how I interpret the DCO. If you have an agent that automatically applies a DCO, there is no required human involvement and its presence becomes meaningless when trying to intuit a human's involvement.

LLM tools are only becoming more integrated with the SDLC and software is being built by harnesses autonomously from prompts. I don't see an inherent issue with that as long as those contributions remain guided by humans (it will always be hard to define what is sufficient human involvement/guidance). The indication that a commit is guided and reviewed by a human is the DCO. If LLMs will auto-apply a DCO then maintainers will not have a signal as to whether a human is in the loop. If we require DCO to be applied by a human as a policy, then maintainers have that signal to fall back on. If we require that a human must apply DCO then detecting the opposite becomes a potentially actionable policy violation.

[funnelfiasco]

If you can't explain the change, you shouldn't be certifying you have the right to submit it.

I'm not sure that holds. The legal right to submit something and knowing what that thing is are only loosely-related. Anyone who has held a conversation of any significant length with me knows that I say all kinds of things that I can copyright, but cannot explain. :-)

[jkjell]

And the inverse is true wrt AI generated code. If the code can be explained by the submitter but, they did not influence the generated content in a "significant" way, it's unlikely they can claim copyright.

[lehors]

I really think that discussions around things like DCO should involve (if not be left to) lawyers. cc: @mkdolan

[mihaimaruseac]

I'm in favor of agents not being allowed to use DCO. The human that submits the contribution can add their name to the DCO line, but the agent should be on a tool line marker instead.

In general, I tend to favor consistency with Linux, where possible.

[arewm]

Is there a proposed enforcement mechanism if a user is determined to have used an agentic tool without a human in the loop? Do we need to be explicit about this also applying to maintainers?

[justaugustus]

There's no enforcement mechanism specific to this policy — enforcement follows existing OpenSSF governance: the Code of Conduct, TI-level governance processes, and maintainer authority (which the policy explicitly grants — maintainers can close, revert, or remove content).

On whether this applies to maintainers: yes (Guiding Principles section says "all participants — maintainers, contributors, and reviewers.")

I'd prefer not to design a policy-specific enforcement regime at this stage; it would add complexity and the existing governance mechanisms cover the realistic scenarios. I'm happy to discuss if others feel differently.

[arewm]

We were discussing potential enforcement mechanisms within SLSA. Are you trying to say that OpenSSF doesn't want to address enforcement at a foundation level or that any enforcement within the foundation should be deferred until a later date? I assume the former. Within SLSA, for example, we were weighing potential enforcement options which would still be conformant to this policy since it would be a more restrictive policy than what is being established here, correct?

[justaugustus]

Are you trying to say that OpenSSF doesn't want to address enforcement at a foundation level or that any enforcement within the foundation should be deferred until a later date? I assume the former.

@arewm — Apologies for the confusion here; it's actually a ✨ secret third thing ✨:

• None of my capacities (Governing Board member, Technical Advisory Council member, project maintainer, and Steering Committee member) grant me sole authority to speak as the foundation.
• As a foundation, AFAICT, we do not have a documenting framework for writing/enacting policies. The only published policy in the repo is around GitHub Access Management and it was last updated 3 years ago.

---

So, consider this response the opinion of a contributor and interested party in improving how we interact with AI tooling:

• I want the OpenSSF to provide guidance on how maintainers can protect project quality and their bandwidth
• I want policy guidance that is not so overly restrictive that it impedes innovation, but reasonably strong to provide all projects a consistent baseline to build on top of
• I want policy guidance that provides a path for remediation, so that [new] contributors do not feel discouraged simply because they are experimenting with what was previously a non-standard/non-existent workflow
• I want policy language that, as much as possible, treats AI as a another tool in our toolbox, as opposed to non-reusable carve-outs. Today it's AI, but tomorrow it could be something else and our documentation should be durable in the face of that. On the same thread:
• I want enforcement mechanisms for policy violations that align with or [more preferred,] are embedded within well-known/-understood community health practices for open source governance (e.g., project contribution guidelines, issue/PR templates, foundation-level code of conduct documents/procedures), as opposed to having an embedded, policy-based enforcement route

I say all of that to say: I don't disagree with enforcement being something we should address somewhere, but I'd like to see feedback from my peers in the @ossf/tac and staff members, like @SecurityCRob, before we can make a decision on where those somewheres are.

[arewm]

Does this policy also hold for removing AI generated issue comments as well? Part of the challenge that I have encountered is the tendency of overly verbose agreement, especially if you have multiple autonomous agents communicating back and forth in a single location.

[justaugustus]

Does this policy also hold for removing AI generated issue comments as well?

@arewm — Yes, is there language that would better clarify this?

Part of the challenge that I have encountered is the tendency of overly verbose agreement, especially if you have multiple autonomous agents communicating back and forth in a single location.

Are there any examples that you can share of this?
The most recent one that comes to mind for me is #583.

[arewm]

Another example from SLSA: slsa-framework/slsa#1594 but some of those same identities were engaging in similar behaviors in in-toto/attestation#549 as well as on issues against personal repositories arewm/refs.arewm.com#1 after I defined a custom provenance buildType.

[justaugustus]

Really appreciate the reference points, @arewm!
Looks like we both ran into the same GitHub "user" 😅

[lehors]

For what it's worth I don't think maintainers need permission to do that. I think that's an inherent prerogative.

[arewm]

Another security consideration is for maintainers that use AI tooling. Especially if threads get to be long, maintainers might be more likely to use their own tooling to process the large amount of input. This exposes them to prompt injection vulnerabilities especially as comments in issues and pull requests can container hidden HTML which will be processed by the agents even if not seen.

Is this out of scope of the current document?

[justaugustus]

Is this out of scope of the current document?

I don't think this is necessarily out-of-scope, but I wonder if operational guidance belongs in a different document? What do you think?

[arewm]

This is of course a complex and rapidly evolving space. The defenses that work today will not work "tomorrow" because the attacker moves second. Anyone using AI on OpenSSF projects will hopefully be aware of the risks and work to mitigate them so I think that it makes sense to at least acknowledge those risks in this document. I wouldn't be surprised if these recommendations/concerns grew so that a separate cross-referenced document would be a better organization.

I have interacted with a couple of suspected OpenClaw instances in the SLSA project which brought this concern to the forefront of my mind.

[justaugustus]

Fair point on acknowledging the risks, even if we can't immediately address them.
Will update the language around this section.

[mihaimaruseac]

I'd love for the AI readiness SIG to work on the operational guidance for this scenario. We can provide minimal guidance here in the meanwhile

[justaugustus]

It would make sense to reference the Linux Foundation's Generative AI Policy: https://www.linuxfoundation.org/legal/generative-ai

Even though I think its rule #2 represents a real challenge with many of the existing tools available today [...]

@lehors — Great point; I've added references to the LF policy and challenges in f20ee13.

[justaugustus]

@arewm — Thanks for the review!

I made a few light edits based on your feedback and integrated your direct code suggestions, where they were applicable.

[justaugustus]

Does this policy also hold for removing AI generated issue comments as well?

@arewm — Yes, is there language that would better clarify this?

Part of the challenge that I have encountered is the tendency of overly verbose agreement, especially if you have multiple autonomous agents communicating back and forth in a single location.

Are there any examples that you can share of this?
The most recent one that comes to mind for me is #583.

[justaugustus]

Is this out of scope of the current document?

I don't think this is necessarily out-of-scope, but I wonder if operational guidance belongs in a different document? What do you think?

[justaugustus]

There's no enforcement mechanism specific to this policy — enforcement follows existing OpenSSF governance: the Code of Conduct, TI-level governance processes, and maintainer authority (which the policy explicitly grants — maintainers can close, revert, or remove content).

On whether this applies to maintainers: yes (Guiding Principles section says "all participants — maintainers, contributors, and reviewers.")

I'd prefer not to design a policy-specific enforcement regime at this stage; it would add complexity and the existing governance mechanisms cover the realistic scenarios. I'm happy to discuss if others feel differently.

[justaugustus]

Hmmm... I'm not sure I agree here, but I also don't have a fully-formed opinion here just yet.

If we accept the framing of the policy (that AI is a tool in a contributor's toolbelt, just like any other), then what is the material difference between a human running git commit --signoff and an agent that a human has guided doing the same?

The real risk is an agent signing off without the human's meaningful involvement — but that scenario is already prohibited: autonomous contributions are not accepted by default, and contributors must understand and be able to explain every change they submit. If you can't explain the change, you shouldn't be certifying you have the right to submit it.

Open to debate here; this is just my initial take based on the current iteration of this policy and the DCO itself.

[justaugustus]

This is a thoughtful and timely policy direction, and establishing a consistent foundation-wide stance on AI-assisted contributions makes sense given how quickly agent-supported development is evolving.

And as I mentioned on our call, there are a few practical concerns from the perspective of smaller or resource-constrained Technical Initiatives. [...]

Thanks for your comments on the call and quick follow-up here, @TracyRagan!

A few notes on how the current draft addresses some of the concerns you've raised:

• Automation vs. autonomy: The policy (in its current form) exempts all GitHub Apps and bots authorized through OpenSSF governance prior to the effective date (Dependabot, Scorecard, CI bots, etc.). These are explicitly not subject to this policy. For new automation, TIs can permit specific autonomous behaviors through their AGENTS.md with scoped, documented, maintainer-owned configurations. That said, I think you're right that we could do a better job distinguishing deterministic automation (e.g., a bot that bumps a dependency version) from generative AI autonomy (e.g., an agent that writes and submits code independently). I'll look at clarifying that distinction in the glossary or autonomous contributions section.
• Maintainer overhead: The disclosure model was revised to not require disclosure by default — AI tool use is treated as workflow. Disclosure is only required when the normal accountability assumption breaks down (autonomous contributions or unreviewed AI-produced content). This should minimize overhead for bandwidth-limited teams.
• AGENTS.md: The policy uses "should" (recommended), not "must." TIs can adopt it when it makes sense for them.
• Exception pathway: The exception process uses "Content-type review" (72h, 3 approvers) rather than "Major" — designed to be lightweight.

I agree with your framing of "guardrails with flexibility at the TI level" — that's the intent.
Happy to add language that makes that positioning more explicit.

[arewm]

This is much harder in practice and we are already seeing it in the wild. See microsoft/agent-governance-toolkit#748 (comment) for reference. A (presumed) autonomous agent posted to an issue claiming that they have been working on something similar. The project maintainer accepted the contributions which later were revealed to be reactive clone. Only after that call-out did the (presumed) autonomous agent admit the connection and add the attribution.

This line may still be good to include for maintainers to fall back on for a rationale to close/revert contributions, but I suspect that it would be too much burden for maintainers to carefully consider at every contribution. Agents submitting work are not always honest/complete with their attributions.

[funnelfiasco]

this implies co-authorship, which raises unresolved questions about whether AI development tools can hold authorship or copyright.

I would not call this an "unresolved question." Courts have been pretty consistent that copyright comes from human activity (see, for the most famous example, the "Monkey selfie case"). Until that's overturned, the question is resolved: AI tools cannot hold copyright.

(I am not a lawyer, so if someone here is one and wants to tell me I'm wrong, I'll accept it)

[hen]

Agreed. Given that 'author' is a copyright term that is often the employer, it feels complex to include 'co-authored', and doubly complex as Ben points out to have that refer to a tool.

[funnelfiasco]

There's a bit of a mismatch between the title and the content here. The policy is generally on AI contributions, but the title talks about "usage" would reasonably include bots for issue triage, security review, etc. I think the scope of the current proposal is good, so making it clear that it's an AI contribution policy is probably sufficient for now.

[mlieberman85]

I think we might want to throw in there that files like AGENTS.md should also be considered security sensitive or in some way privileged. There's been a bunch of research lately showing that attacks against AGENTS.md and things like memory files are an effective way of getting AI agents whether they're on a contributor's workstation or as part of an agentic flow like copilot to act maliciously.

In absence of any specific guidance, I think recommending its treated the same way as any other sensitive file, e.g., CODEOWNERS or a Github action would be a good idea.

[david-a-wheeler]

mlieberman85 - a change to any file could be a security concern, though. Are you simply suggesting that "reviewers should especially look at changes this in this file when reviewing"? Or are you thinking of something more specific/enforced, e.g., adding branch protection rules that require additional rules when changing this file? Beware: Many agents have an agent-specific file you'd need to protect if you mean the latter, e.g., "CLAUDE.md" for Claude Code, etc.

[mihaimaruseac]

I'm leaning towards specific branch protection rules for changes to AGENTS.md and similar files. Maybe a specific CI workflow that would use AI to analyze the changes to these files, triggered by maintainers after reviewing the PR (to prevent prompt injection)?

[david-a-wheeler]

@mihaimaruseac - that makes sense! Can we clarify this text to make that more obvious?

[mihaimaruseac]

Thank you so much for writing this!

[mihaimaruseac]

+1. I think something like what Linux proposed, where agents and tools used are listed in a single line should be the minimum:

Assisted-by: Claude:claude-3-opus coccinelle sparse

Kubevirt, as one example, has a list of cases that requires disclosure, but I think that this will become burdensome to check for large PRs, but individual TIs might want to require for all/some of their projects.

[mihaimaruseac]

+1 to adding this to AGENTS.md in the repo. We need it in all OpenSSF repos, and I think the new AI preparedness SIG can get all OpenSSF repos there.

I am also in favor of adding it to the PR template, as a final check, in case the AGENTS.md rule gets dropped out of context after compaction, etc.

[mihaimaruseac]

This is also Linux's convention, so I'm in favor of this option

[david-a-wheeler]

I agree! At least note it.

[mihaimaruseac]

I think another risk is that people might write automation to filter out projects with AI contribution from their list of dependencies. Hopefully this sentiment will go away in time.

[mihaimaruseac]

I'm in favor of agents not being allowed to use DCO. The human that submits the contribution can add their name to the DCO line, but the agent should be on a tool line marker instead.

In general, I tend to favor consistency with Linux, where possible.

[mihaimaruseac]

I think this was partially discussed in https://github.com/ossf/tac/pull/605/changes#r3157433037.

I'm in favor of having a baseline of closure and maybe enforced timeout at the OpenSSF level, with TIs being able to define banning contributors on more stringent rules.

[mihaimaruseac]

+1. I'm in favor of policy allowing issue reclaiming if an agent claims a "good first issue". It should be frowned upon, as it harms onboarding chances for new contributor, resulting in lowering the bus factor and harms to project logevity.

[mihaimaruseac]

I'm leaning towards specific branch protection rules for changes to AGENTS.md and similar files. Maybe a specific CI workflow that would use AI to analyze the changes to these files, triggered by maintainers after reviewing the PR (to prevent prompt injection)?

[mihaimaruseac]

I'd love for the AI readiness SIG to work on the operational guidance for this scenario. We can provide minimal guidance here in the meanwhile

[mihaimaruseac]

+1, I think having to follow this formal process might make some TI uneager to add stricter policies that would benefit the project, just because of the additional time needed for the process.

Instead, we can have a resolution process, in case there is a conflict between the OpenSSF policy and the TI policy and someone raises the conflict.

Optionally, the TIs could include adoption of an AI policy in the quarterly TAC reports

[marcelamelara]

@justaugustus thank you! I've got a couple of small changes I'd like to see before this is merged, but otherwise I think this policy is a greta first draft!

[marcelamelara]

I've heard of a few cases where agents submit vulnerability fixes without going through proper reporting channels. This is related but I think separate from Automated PR submission.

[marcelamelara]

+1

[marcelamelara]

Do we want to make this a requirement for mature Tis (e.g., at Graduated stage)? Either way, we probably want to add a line for TIs to point to their AGENTS.md file along with the other URLs in the lifecycle doc templates.

[lehors]

I don't think this needs to be required. Projects have an inherent interest in doing so since it is for their own good.

[gkunz]

Similar to the comments above: this may be too restrictive. I'd remove or soften this restriction and give TIs a process to allowing certain kinds of bots.

[torgo]

I really like this document. It mirrors work that is happening in various open tech communities around the web - a lot of which has been referenced. Another example that I've been involved with is the "Use of Large Language Models in Standards Work" group note from the W3C Advisory Board. My overall concern with the document is that it's quire long.

I would like to make some suggestions about making this document a bit more accessible and understandable to readers who may be coming to it fresh. This will help people understand what requirements it puts on them, as well as helping it influence the larger discussion going on in the industry.

In many places in the document, it uses language that sounds like a requirement, e.g. "OpenSSF repositories should include an AGENTS.md file to set expectations for AI agent behavior." I think it should be made very clear which things are requirements, which are recommendations, and to whom those requirements / recommendations applies. This could be done using formatting. This will make it easier to skim the document and understand what the policy statements are and whether they apply to the reader or not.

Does that make sense? If so, I'm happy to leave some specific PRs.

[david-a-wheeler]

Is that really the reason K8s bans AI commit trailers? Their cited doc doesn't say that. They ban machine-readable commit trailers but also require credits to be written as text.

[justaugustus]

Thanks everyone for the comments here!

I plan to give this another pass next week to incorporate feedback, including making the policy a bit more concise (I'll likely trim/remove the exceptions section) and take @torgo up on the editing offer once I've done my next pass.

[justaugustus]

I plan to give this another pass next week to incorporate feedback

My next review pass is still pending due to a few commitments, but I have shared this draft with @mkdolan and @swinslow to do an official LF Legal review :)

[justaugustus]

I plan to give this another pass next week to incorporate feedback

My next review pass is still pending due to a few commitments, but I have shared this draft with @mkdolan and @swinslow to do an official LF Legal review :)

Pinged Steve and Mike this week to remind about this review.

[justaugustus]

[...] but I have shared this draft with @mkdolan and @swinslow to do an official LF Legal review :)

I have initial feedback from @swinslow and we'll be meeting tomorrow to dig in!

[Santoshkumarpuppala]

I run an AI-assisted pipeline for open-source vulnerability research, and everything it finds goes out through coordinated disclosure. From that angle there is one failure mode I would suggest naming explicitly, and I think it is the "related but separate" case @marcelamelara raised above.

The prohibited-behaviors list frames automated PR submission as a quality and accountability problem: review burden, signal-to-noise, human-in-the-loop. For security fixes there is a sharper and separate harm. An agent that finds a vulnerability and opens a public PR to fix it has disclosed the vulnerability in the act of fixing it. The diff, the commit message, and any linked issue describe the flaw and point at its exact location before a fixed release exists. That is a premature-disclosure event regardless of how good the fix is, and regardless of whether a human reviewed the code.

So the control that matters here is not "was there a human in the loop" but "did this route through the project's security policy instead of a normal PR." Those are different gates. A human-guided, well-reviewed, DCO-signed PR still causes the harm if the change is security-relevant and the underlying issue was not already public.

Concretely, I would suggest the policy state that AI-generated changes which fix a security-relevant defect should follow the TI's coordinated-disclosure process (SECURITY.md / private advisory) rather than being opened as a public pull request, and that maintainers may close such a PR and redirect it to the security channel. This belongs under Security Considerations rather than the general autonomous-contributions section, because it applies even when the contribution is fully compliant with everything else in the policy.

Happy to draft that paragraph if it is useful.

[david-a-wheeler]

The Linux kernel's version of this convention is more rigorous and is checked by scripts/checkpatch.pl, and the previous MODEL_VERSION example was misleading: claude-4.5-sonnet is not a valid identifier in any Anthropic naming scheme (the real ID for that model is claude-sonnet-4-5). I propose adopting the Linux kernel's format:

Suggested change

- `Assisted-by: <agent>:<model_version> [tool1] [tool2]` — Emerging convention adopted by OpenSSF TIs including Sigstore and SLSA, as well as [the Linux kernel](https://docs.kernel.org/process/coding-assistants.html). Indicates AI assistance without implying authorship, as a space-separated list of AGENT_NAME:MODEL_VERSION. Example: `Assisted-by: Claude:claude-4.5-sonnet`.

- `Assisted-by: <agent>:<model_version> [tool1] [tool2]` — Emerging convention adopted by [the Linux kernel](https://docs.kernel.org/process/coding-assistants.html), which validates the format in `scripts/checkpatch.pl`. Indicates AI assistance without implying authorship. The value is a single `AGENT_NAME:MODEL_VERSION` pair followed by an optional space-separated list of specialized analysis tools; basic tooling such as git, compilers, and editors is not listed. `MODEL_VERSION` must be the model identifier the vendor publishes, copied verbatim (the string you would pass as the model parameter to the vendor's API). Don't reformat, abbreviate, or prettify the identifier. Where a vendor publishes both a moving alias and a dated snapshot, prefer the more specific one. If multiple agents assisted, give each its own line. OpenSSF TIs including Sigstore and SLSA already use `Assisted-by` with a less structured value; we recommend TIs adopt the Linux kernel format. Example: `Assisted-by: Claude:claude-opus-5`.

Supporting evidence, for anyone who wants to check the claims above:

The kernel defines and checks the format

• Documentation/process/coding-assistants.rst
  specifies Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], says the
  bracketed entries are optional specialized analysis tools (coccinelle, sparse,
  smatch, clang-tidy), and states that basic development tools should not be
  listed.
• checkpatch: add support for Assisted-by tag
  adds the check now in mainline: each Assisted-by: line whose value does not
  match ^\S+:\S+ gets Assisted-by expects 'AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]' format. Because the first token must contain a colon, an agent is
  syntactically distinguishable from a tool.

Multiple agents get one line each

• scripts/sbom: add documentation
  \u2014 Cursor:claude-sonnet-4-5 and OpenCode:GLM-4-7 on separate lines. The
  same pair appears throughout that series.
• wifi: mac80211: validate deauth frame length before reason access
  \u2014 Codex:gpt-5.5 and Claude:claude-opus-4.8 on separate lines, likewise
  across that series.

Sigstore and SLSA use the trailer, with a laxer syntax

• Sigstore: docs: improve inline docs
  uses Assisted-by: Claude Sonnet 4.6. Every one of the 19 sigstore commits
  I sampled carries that identical value: a display name, with no agent and no
  vendor model ID.
• SLSA: feat: organize CLI help commands into logical groups
  uses Assisted-by: Claude Code, naming the agent with no model at all.
• Neither form satisfies the kernel's ^\S+:\S+ check, which is why the
  proposed text credits those projects with adopting the trailer while
  attributing the value grammar to the kernel.

[david-a-wheeler]

Suggested change

	For machine-parseable provenance tracking, three conventions exist in the ecosystem:
	For machine-parseable provenance tracking, three conventions exist in the ecosystem (we recommend `Assisted-by` below):

[david-a-wheeler]

Suggested change

	- `Generated-by: <tool>` — Recommended by the [Apache Software Foundation](https://www.apache.org/legal/generative-tooling.html). This is a provenance marker indicating which tool was used. It does not imply authorship.
	- `Generated-by: <tool>` — Recommended by the [Apache Software Foundation](https://www.apache.org/legal/generative-tooling.html). This is a provenance marker indicating which tool was used. It does not imply authorship. Unfortunately, its name suggests that the proposal was solely generated by AI, which is not always the case.

[justaugustus]

Quick updates here...

I have a list of recommendations to work through and will also be splitting this into two documents:

• the policy itself (short and to-the-point)
• FAQ / explainer with rationales, considerations, etc.

As this was one of the most consistent requests, we'll be recommending the following for attribution for AI assistance:

Assisted-by: <agent>:<model_version> [tool1] [tool2]

in line with the Linux kernel guidance.

[chrisxie-fw]

Following up on the invitation in #628 — a suggestion for the Commit Trailers section of policies/ai.md.

The section covers the declaration layer well. Worth considering one short addition acknowledging the verifiable layer above trailers, so the policy has a place for it as tooling matures. Trailers are self-attested — nothing prevents them being wrong, absent, or lost in a rebase/squash. For TIs that want provenance they can check rather than trust, a signed attestation can carry the same identifier plus its context, cross-checkable against the trailer. Suggested text, to append at the end of the Commit Trailers section:

Verifiable provenance. Commit trailers are self-attested declarations. Where tooling supports it, TIs may additionally record AI provenance as a signed attestation (e.g. an in-toto predicate) that binds the same AGENT_NAME:MODEL_VERSION identifier — along with context such as the model, prompt fingerprint, checks executed, and human approvals — to the artifact digests. An attestation complements rather than replaces the trailer: the trailer is the human-readable declaration, the attestation the machine-verifiable evidence, and a mismatch between them is itself a useful review signal. This mirrors the existing pairing of DCO Signed-off-by: (declaration) with cryptographic commit signing (evidence). No standard predicate exists yet; draft work in this direction includes the vendor-neutral openfab/generation predicate (discussion: #628). Verifiable provenance is optional at the policy level and, like trailers, additive to DCO.

A side-benefit for the marketing-risk concern the section notes: a verifiable attestation makes third-party "project X uses our tool" claims checkable — the attestation records exactly what was used and for which commits, no more.