A good bot policy fits in one short section of CONTRIBUTING.md: which bots may open pull requests, what each needs before merging, how many may be open at once, who reviews, and how people can ask a bot to stop. Write it once and link to it in every reply.
Why write it down
Without a policy, every bot pull request becomes a fresh decision, and every stranger's bot gets the same hearing as the one you installed. A written rule saves you time and tells contributors what to expect. It also protects you when you say no, because you are applying a rule rather than a mood.
What to include
| Topic | Question it answers |
|---|---|
| Allowed bots | Which tools may open pull requests here? |
| Evidence | What must a pull request show before review? |
| Review | Who reviews, and does a bot ever merge itself? |
| Limits | How many automated pull requests can be open at once? |
| Opt out | How does a maintainer stop a bot? |
| Security reports | Where do real vulnerability reports go? |
A sample section
## Automated pull requests
- We accept pull requests from the dependency update bot we run on
this repository. Other bots and scripts need a maintainer's
agreement first. Open an issue to ask.
- Security fixes must include steps to reproduce the problem and a
test that fails before the change and passes after it.
- Dependency updates are reviewed by a maintainer. Nothing merges
without passing required checks.
- We keep a small number of automated pull requests open at a time.
Extras may be closed and will come back later.
- To stop a bot, comment on its pull request or open an issue.
- Do not report vulnerabilities in a public pull request. Follow
SECURITY.md instead.
Adjust it to your project. The point is that every line is something you will actually enforce.
Limits are configurable
If you run Dependabot yourself, GitHub's documentation says version updates default to five open pull requests at a time, and that security update pull requests have a separate fixed limit of 10 that cannot be changed with the option. You can set the version update limit lower, or to zero to pause version updates for an ecosystem. Matching your written rule to the config means the policy and the tool agree.
Cover the opt-out path
GitHub documents comment commands for Dependabot, including ignoring a dependency or a major, minor, or patch version. Mention in your policy that maintainers can use them, and that ignoring is stored centrally unless you record it in the configuration file. The docs recommend putting ignore rules in the config file for repositories with more than one contributor so everyone can see why a dependency is not being updated.
Link it everywhere
Reference the section from your pull request template, from SECURITY.md, and from your standard reply to unwanted automated pull requests. See a contribution policy for your own open source project for the human contributor side.
Where Safeguard fits
Safeguard's policies, gates and guardrails apply the same idea inside companies that consume open source: written rules enforced as checks. Maintainers can try a free scan at https://gold.safeguard.sh/scan to see how their own project looks to a downstream user.
Quick check
Do I need a policy if I only use one bot?
A short one still helps. It covers the bots you did not install and makes your own bot's limits visible.
Should the policy name specific tools?
Name the ones you run. Say that others need agreement first, so the list does not go stale.
Sources
- Dependabot options reference, GitHub Docs
- Dependabot pull request comment commands, GitHub Docs
- Managing pull requests for dependency updates, GitHub Docs
Last reviewed: 19 October 2026.
