Why do auto merge workflows become risky when they rely on Dependabot identity alone?

Why This Matters for Security Teams

Auto merge checks that trust Dependabot identity alone create a gap between the branch creator and the event actor. In GitHub-based workflows, the merge decision is often made from the last triggering identity, which can be influenced by repository activity rather than by the original source of the pull request. That makes the approval path look deterministic while still being reachable through indirect manipulation.

This matters because automation is usually deployed to reduce review friction, not to weaken trust boundaries. If a workflow treats a bot-triggered refresh as proof of legitimacy, an attacker may only need to nudge the bot into re-running the job. The result is not a broken secret or a noisy alert, but an incorrect authorization decision that promotes code through the intended control plane. That is a governance failure as much as a CI/CD failure, and it maps closely to the control intent behind the NIST Cybersecurity Framework 2.0.

In practice, many security teams discover this only after a trusted automation path has already accepted a change it should never have considered eligible.

How It Works in Practice

The risky pattern appears when a workflow uses a condition like “merge if the actor is Dependabot” without also proving that the triggering event, branch state, and pull request origin all match the intended trust model. Dependabot is a useful automation identity, but it is not a substitute for authorization context. A bot can refresh dependency branches, reopen a pull request, or cause a job to rerun, and the workflow may then see the bot as the current actor even though the original change was created or influenced elsewhere.

Practitioners should separate identity from intent and add checks that are resistant to event spoofing or retriggering. The strongest patterns usually combine:

• verification of the pull request source and commit lineage, not just the current actor;
• path and file scope restrictions for automated merges;
• branch protection rules that require independent checks to pass before merge;
• manual approval for changes that affect build logic, workflow files, or dependency update rules;
• logging that preserves both the original author and the final event actor for review.

Control design should also reflect broader baseline expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where software change control, least privilege, and integrity monitoring intersect. Current guidance suggests treating automation identities as constrained subjects, not trusted decision-makers. In environments with high commit velocity, the safer model is to let Dependabot propose and validate updates while a separate policy layer decides whether a merge is allowed. These controls tend to break down when multiple reusable workflows, nested approvals, and broad repository write permissions all converge in the same pipeline.

Common Variations and Edge Cases

Tighter merge controls often increase operational overhead, requiring organisations to balance release speed against the risk of silently promoted code. That tradeoff becomes more visible in repositories with heavy dependency churn, monorepos, or teams that depend on fully automated patching to meet patch windows.

Best practice is evolving for cases where automation identities are used as part of a broader trust chain. There is no universal standard for this yet, but a practical approach is to reserve bot-based auto merge only for low-risk updates and require stronger review paths for anything that changes build steps, workflow definitions, or authentication logic. When a repository supports multiple automation sources, the trust policy should distinguish between a bot that opened or refreshed a pull request and a bot that merely appears in the latest event context.

Identity is the intersection point here: Dependabot can be a legitimate automation identity, but it should not be treated as a standalone proof of provenance. Where organisations also use agentic automation or other non-human identities, the same rule applies. A machine identity can initiate work, but it should not be the only basis for approval. The error usually appears in repositories that assume “bot equals safe” and then allow inherited trust across reruns, refreshes, and chained workflows.

Related resources from NHI Mgmt Group

• Why do secrets become risky when they are detached from identity context?
• What do teams get wrong when they rely on identity checks alone for compliance in Australia?
• When does manual data classification become too risky to rely on?
• When does manual control testing become too risky to rely on?