Because attribution and revocation depend on it. If a fix bot uses a developer's token or a shared admin account, you cannot tell its changes from a human's, and you cannot cut it off without disrupting a person. A dedicated identity with narrow scopes and signed commits solves both.
Definitions
Bot identity means an account or app that exists only for the automation, with its own credentials and owner.
Signed commit means a commit carrying a cryptographic signature that the platform can verify. GitHub's branch protection can require that only signed and verified commits are pushed to a protected branch.
A signature shows that a commit came from a holder of a key. It does not show that the change is good.
What goes wrong without a dedicated identity
- Audit logs show a developer made changes the developer never saw.
- Revoking access to stop the bot also locks out a colleague.
- The token carries the developer's broad rights, which is the excessive permissions pattern OWASP warns about.
- When the developer leaves, the automation breaks, or worse, keeps running on an orphaned credential.
Setting it up
- Create the identity as an app or machine account, owned by a team, not a person.
- Scope it narrowly. Permissions to create branches and open pull requests in enrolled repositories. No admin, no ability to edit protection rules or workflows.
- Keep it off bypass lists. By default, admins and holders of bypass permission are exempt from branch rules. The bot should never be among them.
- Sign commits. Configure signing for the identity and consider requiring signed commits on the branches it targets.
- Name an owner and a rotation date. Put both in the same place as the bot's documentation.
- Store credentials in a secrets manager, not in repository files or developer machines.
What you gain
| Benefit | How |
|---|---|
| Attribution | Every commit and pull request carries the bot's name |
| Revocation | Disable one identity without touching people |
| Scope control | Permissions match the job and nothing else |
| Auditability | Queries by actor return exactly the bot's activity |
| Policy hooks | Rules can treat bot pull requests differently, such as always requiring review |
A caution about signing
A signed commit proves origin, not safety. If the bot's key or token is stolen, an attacker produces signed commits that look legitimate. Signing helps only alongside review, narrow scope and monitoring. Watch for the bot acting at unusual hours, on unenrolled repositories, or on files outside its normal area, and alert on any of them.
Review cadence
Each quarter, list what the identity can access, which keys it holds and when they were last rotated. Remove anything unused. This is a small job when done regularly and a large one after an incident.
For agent systems more generally, the same pattern appears: one identity per agent, least privilege, logging. The related post on what permissions a remediation bot should have lists scopes in more detail.
Safeguard offers autonomous remediation with fix PRs, off by default and Manual in every category, and agent identity as a capability. Whatever tool you choose, give automation an identity of its own.
Quick check
Does a signed commit mean the fix is safe?
No. It shows who signed it. Safety still comes from review, tests and scope limits.
Can the bot share a service account with other automation?
Avoid it. Shared accounts blur attribution and make revocation disruptive. Use one identity per automation.
Sources
Last reviewed: 19 October 2026.
