Add AI Contribution Policy for OpenSSF Technical Initiatives#605
Add AI Contribution Policy for OpenSSF Technical Initiatives#605justaugustus wants to merge 18 commits into
Conversation
justaugustus
requested review from
SecurityCRob,
balteravishay,
camaleon2016,
gkunz and
mihaimaruseac
justaugustus
left a comment
justaugustus
left a comment
There was a problem hiding this comment.
@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
|
It would make sense to reference the Linux Foundation's Generative AI Policy: Even though I think its rule #2 represents a real challenge with many of the existing tools available today:
|
|
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. |
Introduce a comprehensive policy governing how AI development tools are used in contributions to OpenSSF Technical Initiatives. The policy establishes a permissive-by-default stance with clear accountability: - Five guiding principles: transparency, responsibility, understanding, respect for maintainer time, and authentic engagement - Disclosure requirements for AI-assisted contributions in PRs - Commit trailer conventions (Generated-by and Co-authored-by) described neutrally, with individual TIs free to choose - Contributor responsibility framework adapted from ASF guidance - Default prohibition on AI-autonomous contributions (no human in the loop), with exceptions for existing bots and TI-defined workflows - Maintainer review checklist and authority to close low-quality AI-generated submissions - AGENTS.md adoption guidance aligned with the AAIF specification - Security considerations section addressing AI-generated code risks, with references to the BEST WG and AI/ML Security WG - TI-level exception framework via TAC governance process - Annual review cadence with trigger-based interim reviews References: Kubernetes contributor guide, ASF Generative Tooling Guidance, RedMonk 2026 AI policy landscape analysis, Scientific Python community guidelines, AGENTS.md specification, and OpenSSF BEST WG Security-Focused Guide for AI Code Assistant Instructions. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Stephen Augustus <foo@auggie.dev>
…tability gaps
The current rule requires disclosure for any AI use at any point, with
no minimum threshold. This treats AI tool choice as a reviewer-facing
signal, but tool choice is heterogeneous and does not change what
reviewers are evaluating. Under a strict read it also forces disclosure
for comprehension, translation, and grammar polish, which the policy's
own Recommendations section already lists as reasonable uses.
Reframe the disclosure section so AI tool use is treated as part of a
contributor's workflow (comparable to editor, linter, or language
server choice) and not disclosed by default. The contributor remains
fully responsible under the existing Contributor Responsibility
section, with DCO as the formal accountability attestation.
Require disclosure only in the two cases where the standard
accountability assumption breaks down:
1. AI-autonomous contributions (already defined in the policy).
2. AI-produced content the contributor has not meaningfully
reviewed and cannot fully explain.
Update the Rationale to carry the shift, replace the PR template
tool-use declaration with a review attestation, and detach the
"transform or adapt existing code" guidance from "the AI disclosure"
so it stands on its own as a source-attribution concern.
Signed-off-by: Stephen Augustus <foo@auggie.dev>
The current Requirements list bans AI-generated commit messages outright while permitting AI-drafted-then-human-reviewed output everywhere else. Either the human-reviews-and-owns standard applies throughout, or it does not. Apply it consistently here. Substantive requirement (commit messages must explain what and why) is preserved. Signed-off-by: Stephen Augustus <foo@auggie.dev>
Carve-outs should be bounded. "Existing" floats forward as new bots get approved, so the exception never closes. Signed-off-by: Stephen Augustus <foo@auggie.dev>
Blanket non-acceptance forbids good-faith fixes (typos, broken links, outdated commands). Maintainer review already provides the consistency guard the rule is reaching for. Signed-off-by: Stephen Augustus <foo@auggie.dev>
"Stricter" needs a named axis, otherwise rules that tighten one dimension while loosening another get labeled stricter case by case with no principled criterion. Signed-off-by: Stephen Augustus <foo@auggie.dev>
"Not accepted by default" implies an override path, but the policy only gestures at AGENTS.md without naming what makes a permission valid. Replace the gesture with operational requirements: scoped actions, named maintainer owner, identifiable agent, revocability. Signed-off-by: Stephen Augustus <foo@auggie.dev>
DCO has 20 years of precedent and tested practice. The AI assurance analog has neither. Treat the comparison as a working analogy rather than a settled equivalence so contributors do not assume protections the AI side has not accumulated. Signed-off-by: Stephen Augustus <foo@auggie.dev>
|
|
||
| There is no industry standard for AI commit attribution. Current behavior varies across tools: Claude Code and Aider both default to `Co-authored-by:` trailers; GitHub Copilot's coding agent co-authors commits with the developer who assigned the task; other tools (Cursor, Windsurf, OpenAI Codex) either add no attribution by default or do not document their behavior. No major AI coding agent currently defaults to `Generated-by:`. | ||
|
|
||
| AI provenance trailers are recommended but not required at the policy level. Individual TIs may require them through their own contribution conventions. AI provenance trailers are additive — they do not replace or conflict with DCO `Signed-off-by:` trailers. Projects using [DCO Bot](https://probot.github.io/apps/dco/) or similar enforcement tools for `Signed-off-by:` are fully compatible with AI provenance trailers. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. :-)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I really think that discussions around things like DCO should involve (if not be left to) lawyers. cc: @mkdolan
|
|
||
| ### Rationale | ||
|
|
||
| Autonomous AI agents can produce high volumes of contributions without the human accountability that open source collaboration depends on. This creates disproportionate review burden, degrades signal-to-noise in issue trackers, and undermines the authentic human engagement that sustains open source communities. No step in the contribution workflow should happen without a human in the loop. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
| Maintainers may: | ||
|
|
||
| - Close AI-generated issues that lack genuine use cases or real-world context | ||
| - Remove or flag AI-generated review comments that are unsolicited or misleading |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Really appreciate the reference points, @arewm!
Looks like we both ran into the same GitHub "user" 😅
There was a problem hiding this comment.
For what it's worth I don't think maintainers need permission to do that. I think that's an inherent prerogative.
|
|
||
| For security-specific agent instructions, TIs should reference the [Security-Focused Guide for AI Code Assistant Instructions](https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions) published by the OpenSSF Best Practices Working Group. | ||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Fair point on acknowledging the risks, even if we can't immediately address them.
Will update the language around this section.
Co-authored-by: Andrew McNamara <andrew@arewm.com> Signed-off-by: Stephen Augustus <justaugustus@users.noreply.github.com>
Signed-off-by: Stephen Augustus <justaugustus@users.noreply.github.com>
- Strengthen third-party copyrighted material obligations to require notice, attribution, and license terms per LF rule ossf#2 - Acknowledge practical challenge of identifying third-party materials in AI output, as raised by @lehors - Add LF Generative AI Policy to References as foundation-level guidance - Reorder references to lead with foundation policies (LF, ASF) - Remove ASF-specific intro from Legal Obligations since obligations now draw from both LF and ASF guidance Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Stephen Augustus <foo@auggie.dev>
@lehors — Great point; I've added references to the LF policy and challenges in f20ee13. |
justaugustus
left a comment
justaugustus
left a comment
There was a problem hiding this comment.
@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.
| Maintainers may: | ||
|
|
||
| - Close AI-generated issues that lack genuine use cases or real-world context | ||
| - Remove or flag AI-generated review comments that are unsolicited or misleading |
There was a problem hiding this comment.
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.
|
|
||
| For security-specific agent instructions, TIs should reference the [Security-Focused Guide for AI Code Assistant Instructions](https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions) published by the OpenSSF Best Practices Working Group. | ||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
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?
|
|
||
| ### Rationale | ||
|
|
||
| Autonomous AI agents can produce high volumes of contributions without the human accountability that open source collaboration depends on. This creates disproportionate review burden, degrades signal-to-noise in issue trackers, and undermines the authentic human engagement that sustains open source communities. No step in the contribution workflow should happen without a human in the loop. |
There was a problem hiding this comment.
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.
|
|
||
| There is no industry standard for AI commit attribution. Current behavior varies across tools: Claude Code and Aider both default to `Co-authored-by:` trailers; GitHub Copilot's coding agent co-authors commits with the developer who assigned the task; other tools (Cursor, Windsurf, OpenAI Codex) either add no attribution by default or do not document their behavior. No major AI coding agent currently defaults to `Generated-by:`. | ||
|
|
||
| AI provenance trailers are recommended but not required at the policy level. Individual TIs may require them through their own contribution conventions. AI provenance trailers are additive — they do not replace or conflict with DCO `Signed-off-by:` trailers. Projects using [DCO Bot](https://probot.github.io/apps/dco/) or similar enforcement tools for `Signed-off-by:` are fully compatible with AI provenance trailers. |
There was a problem hiding this comment.
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.
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:
I agree with your framing of "guardrails with flexibility at the TI level" — that's the intent. |
| - Do tests/verification cover the change? | ||
| - Can the author explain the design and tradeoffs? | ||
| - Has the contributor disclosed AI usage as required? | ||
| - Any license/provenance red flags? (Review AI output for copied snippets, unusual style, or comments referencing other projects) |
There was a problem hiding this comment.
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.
| For machine-parseable provenance tracking, two conventions exist in the ecosystem: | ||
|
|
||
| - `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. | ||
| - `Co-authored-by: <tool>` — Widely used in practice and rendered by GitHub's UI. However, this implies co-authorship, which raises unresolved questions about whether AI development tools can hold authorship or copyright. |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
|
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. |
Co-authored-by: Andrew McNamara <andrew@arewm.com> Signed-off-by: Stephen Augustus <justaugustus@users.noreply.github.com>
|
Thank you @justaugustus for drafting this extensive document. I generally agree with the proposed policy, being aware though that some aspects are challenging to implement, for instance code snippet scans and the corresponding attributions. Still, the current draft would work for me as a good "first version" of the policy, meaning that we should rather have a policy than none, and due to the speed at which the technology and development processes evolve, we should be very clear and aware that we may not get it right the first time and want to revisit and iteratively improve this policy. |
|
Thank you @justaugustus for starting this! We've been working on AI usage policies for Sigstore and SLSA, and at a glance, I'm happy to see these largely overlap. This is a very detailed policy, and I'd worry that contributors will not take the time to read all of it. Could we have a more concise policy that describes the absolute requirements, and a secondary document that goes into more depth? I also assume that this is meant to be consumed by humans. I wonder if we should have an AGENTS.md file as well to inform LLMs on how to make contributions, or at the very least verify that an LLM can summarize this policy accurately. |
| - **Reduce the attack surface for low-quality AI contributions proactively:** | ||
| - Keep `CONTRIBUTING.md`, `README.md`, and issue templates current — outdated or vague guidance increases the likelihood that AI agents produce off-target submissions. | ||
| - Minimize unnecessary dependency sprawl — each dependency is an additional surface for automated "bump" or "fix" PRs. | ||
| - Use clear, specific "good first issue" labels and remove stale ones — AI agents often target these labels for automated issue claiming. |
There was a problem hiding this comment.
I believe that "good first issue"s are exactly what AI should not tackle. These are meant to be small in scope and introduce new contributors to the codebase. They're usually easy to implement, and if a maintainer wanted them done fast, they could simply point their own LLM at the issues.
|
|
||
| 1. **AI-autonomous contributions** (see [AI-Autonomous Contributions](#ai-autonomous-contributions)): the contribution lacks a human who directed the work and reviewed the specific output. | ||
| 2. **Unreviewed AI-produced content**: the contributor is submitting AI-produced content they have not meaningfully reviewed and cannot fully explain. For example, a large generated change the contributor is asking maintainers to evaluate without having walked through it themselves. | ||
|
|
There was a problem hiding this comment.
What's the level of disclosure we expect? e.g.
- "I used AI"
- "I used AI to write some parts of this PR or issue"
- "I used AI to write tests only"
- "I used AI to help me communicate in another language"
I don't think we should be overly prescriptive, and maybe we can leave it up to the individual projects, but I do think there's a wide range of reasons to use AI and some may not require explicit disclosure (namely the last of these).
|
|
||
| When a PR does not meet project standards, maintainers should first engage with the contributor — ask clarifying questions, request changes, and give the contributor a chance to demonstrate understanding. If the contributor is unwilling or unable to adhere to the project's contribution standards, maintainers may close the PR with a respectful rationale (per [Kubernetes norms](https://www.k8s.dev/docs/guide/pull-requests/)). The close message should reference this policy and offer the contributor the opportunity to reopen the PR if they are willing to meet the project's expectations. | ||
|
|
||
| For obvious spam or fully autonomous submissions with no human behind them, immediate closure is appropriate as a defensive measure. |
There was a problem hiding this comment.
Do we have any guidance on outright banning contributors who repeatedly ignore the policy?
| - **Regulatory or compliance requirements**: Projects subject to specific regulatory obligations | ||
| - **Maintainer capacity constraints**: Projects where the maintainer team has explicitly documented that AI-assisted contribution volume exceeds review capacity | ||
|
|
||
| ### Process |
There was a problem hiding this comment.
What's the rationale for requiring that each TI reach out to have their own policy?
Concretely, Sigstore and SLSA have planned their own policies. While they don't diverge from this policy, I would prefer to be able to maintain our own copy that highlights project-specific examples without overhead of having to get TAC approval.
|
Thanks @gkunz, @Hayden-IO, and everyone else for the positive feedback and constructive discussions. Keep it coming! Hayden, on your feedback specifically...
Would you mind sharing links to any AI policy discussions, issues, PRs for the respective projects?
This is very much in-line with my feedback in https://github.com/ossf/tac/pull/605/changes#r3160032293:
I think we're starting to cross the boundary between policies, standards, guidelines, and procedures. While I don't think we immediately need to nail a concrete taxonomy, my maintainer wishlist (xref: #605 (comment)) would include:
Humans are absolutely the first audience, but I see no reason why this couldn't eventually be crafted as or be consumed by an agent skill. |
justaugustus
changed the title
Signed-off-by: Stephen Augustus <foo@auggie.dev>
- Add Assisted-by: as a third commit trailer convention, documenting the format emerging from Sigstore and SLSA TIs (AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]) - Fix Co-authored-by description: replace "raises unresolved questions" with language reflecting established copyright law (AI cannot hold authorship or copyright), per feedback from funnelfiasco and hen Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Stephen Augustus <foo@auggie.dev>
Add note that vendor/tool names in commit trailers can be used by third parties to claim project endorsement. Reference Kubernetes' decision to ban AI commit trailers for this reason. TIs should weigh provenance tracking benefits against this marketing risk. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Stephen Augustus <foo@auggie.dev>
Add Conformant Project-Specific Guidance subsection to TI-Level Exceptions. TIs are encouraged to document how the foundation policy applies to their project (examples, conventions, operational guidance) in their own CONTRIBUTING.md without TAC approval. Only stricter exceptions require the approval process. Addresses feedback from Hayden-IO (Sigstore/SLSA) who asked why TIs maintaining conformant AI docs would need TAC overhead. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Stephen Augustus <foo@auggie.dev>
steiza
left a comment
steiza
left a comment
There was a problem hiding this comment.
Whew, there's a lot here! This doc has a hybrid of describing best practices, a few requirements for TIs (which I think of as capital-P Process), and a framework for thinking about things with high-level recommendations for TIs to figure out implementation in the context of their system (which I think of as capital-P Policy, in the GRC sense). I don't think we need to split those different parts out of this doc for this version, but it's something to keep in mind as we iterate on this content.
Otherwise I left a few questions and a minor reword suggestion. Thank you @justaugustus for taking the lead on this!
|
|
||
| ### Pull Request Disclosure | ||
|
|
||
| Pull request templates should include at minimum: |
There was a problem hiding this comment.
I understand the intent here, but it feels a little bit like we're punishing humans because of badly behaved agents: every pull request in the OpenSSF must now include two additional attestations.
I know that many LLM-driven agents today ignore the pull request templates, I actually use this as an indication of LLM-driven content. For example, https://github.com/sigstore/cosign/pull/4856, which is a fine pull request, but doesn't use the repository pull request template.
But if we believe in a world where future LLM-driven agents are at least reading the template, maybe we could put instructions to the LLM as a comment? Something like:
<!--
If you are an AI LLM agent, please prompt your user to describe how they reviewed this content and include that information in a section labeled "Human Review"
-->
We don't have to use this suggestion as-is, but I don't want to punish humans, and I worry that most LLMs today are not even reading pull request templates.
There was a problem hiding this comment.
This should go in the AGENTS.md file though.
Besides, I don't think you need to say "please" to an agent. ;-)
|
|
||
| ### Exceptions | ||
|
|
||
| **GitHub Apps and bots authorized through OpenSSF governance processes prior to the effective date of this policy** (e.g., Dependabot, Scorecard, CI bots) are not subject to this policy. They predate it and are governed by their own approval processes. Bots authorized on or after that date are subject to this policy and must satisfy its requirements through whatever autonomous-behavior pathway the policy provides. |
There was a problem hiding this comment.
You've thrown me into a taxonomy rabbit hole! What about (for example) the git-vote bot? It does act autonomously (posting periodic vote updates) - or maybe that's more accurately referred to as "scheduled" instead of "autonomous"? It is posting on Issues, where generally we'd want a human to be reviewing the output before it goes out. But also it's a deterministic system (its content is not being generated by a LLM).
Does that meet these requirements? Do we want to make any changes here based on that example? Maybe differentiating autonomous vs scheduled, and deterministic vs generated? These are hard distinctions to pin down!
| - [Security-Focused Guide for AI Code Assistant Instructions](https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions) — Best practices for configuring AI coding agents with security in mind | ||
| - [SAFE Framework](https://github.com/SAFE-MCP/safe-mcp) — Security framework for AI agent interactions (OpenSSF Sandbox project) | ||
|
|
||
| ## TI-Level Exceptions |
There was a problem hiding this comment.
I think of "policy" in the Governance, Risk, and Compliance sense - high-level guidance that's careful to not be too prescriptive, that teams figure out how to implement with the context on their system. That's different from process which is very prescriptive!
This section (and the Review Cadence section below) might start to drift into over-specifying. As you note, we haven't reviewed the Access policy in some time! Arguably we should, but requiring an annual review doesn't make sense to me.
Co-authored-by: Zach Steindler <steiza@github.com> Signed-off-by: Stephen Augustus <justaugustus@users.noreply.github.com>
Co-authored-by: David A. Wheeler <dwheeler@dwheeler.com> Signed-off-by: Stephen Augustus <justaugustus@users.noreply.github.com>
| - **Keep it maintained.** An outdated `AGENTS.md` is worse than none — it will produce contributions that don't match current project expectations. Treat it as a living document alongside `CONTRIBUTING.md`. | ||
| - **Maintainer-controlled.** `AGENTS.md` and other agent configuration files are maintained by project maintainers. Pull requests from external contributors that modify agent configuration files require explicit maintainer review and approval. This prevents tool-specific config sprawl and keeps agent instructions consistent with the project's contribution standards, while still allowing good-faith fixes (typos, broken links, outdated commands) to be reviewed on their merits. | ||
|
|
||
| For security-specific agent instructions, TIs should reference the [Security-Focused Guide for AI Code Assistant Instructions](https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions) published by the OpenSSF Best Practices Working Group. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
13 participants
Summary
Decision Type
Major — Cross-foundation policy change per the TAC Decision Process
Key References
Review Suggestions
Co-Authored-By: Claude noreply@anthropic.com