Accountability should remain with the organisation that defines the policy, not with the automation itself. Security teams, platform engineering, and application owners should agree on trigger criteria, approval boundaries, and exception handling before deployment. Automation can execute responses, but governance still requires clear ownership for policy quality, review outcomes, and production impact.
Why This Matters for Security Teams
When automated workflows block merges or open pull requests, the practical risk is not that the tool made a bad call on its own. The risk is that the organisation has not defined who owns the policy, who can override it, and who reviews false positives. That gap can slow delivery, create shadow exceptions, and blur accountability across security, platform, and application teams.
Security automation is most effective when it is treated as an enforcement layer for an agreed control, not as the control owner. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it anchors accountability in governance, access control, and change management rather than in the workflow engine itself. If a merge is blocked for a dependency risk, the real question is whether the blocking criteria were approved, monitored, and tuned by the right owner.
In practice, many security teams encounter blame only after a release is delayed or a critical exception has already been granted without review.
How It Works in Practice
Accountability should follow the control objective. If a workflow blocks a merge because of a failed policy check, the policy owner is accountable for defining what the check means, the platform team is accountable for implementing the automation correctly, and the application owner is accountable for remediating or justifying the exception. Automation can enforce the decision, but it should not be the decision-maker in governance terms.
Operationally, mature teams separate three layers:
-
NIST SP 800-53 Rev 5 Security and Privacy Controls for policy intent, approval authority, and auditability.
-
Pipeline rules for detecting the condition, such as secret exposure, dependency severity, or unsigned artefacts.
-
Exception handling for time-bound overrides, escalation paths, and documented risk acceptance.
This approach becomes especially important when pull requests are opened automatically by scanners or bots. In that case, the organisation still needs ownership of the remediation decision, because the automation may surface a problem faster than humans can triage it. The workflow should also preserve evidence: what triggered the action, which policy version applied, who approved the outcome, and whether the response was preventive or corrective.
For teams operating in Git-based delivery, this often intersects with identity and privilege. A bot or service account may have permission to open a pull request, but that does not make it accountable for the security decision. The accountable party is the one who authorised the bot, defined its scope, and accepted the impact of blocking or modifying merges under that policy. Guidance from the NIST AI Risk Management Framework is increasingly relevant when automated systems make recurring judgement-like decisions, because ownership must still be traceable even when execution is machine-driven.
These controls tend to break down when a single pipeline owns both enforcement and exception approval, because the same team ends up judging the policy, operating the automation, and absorbing release pressure.
Common Variations and Edge Cases
Tighter merge controls often increase delivery friction, requiring organisations to balance release speed against the need for predictable security governance. There is no universal standard for this yet, especially when agentic tools can create pull requests, request approvals, or open issues at scale. Current guidance suggests treating those actions as delegated execution, not delegated accountability.
Edge cases usually appear in shared-platform environments. A central security team may own the rule set, but product teams may own the service risk. In regulated environments, that split must be explicit so that audit evidence shows who accepted the risk and who merely implemented the control. This is also where OWASP Top 10 for Large Language Model Applications becomes relevant if AI assistants are generating code changes or remediation suggestions that enter the same approval path as human-authored commits.
Another common edge case is auto-remediation. If a bot opens a pull request to fix a vulnerability, the bot is not the accountable actor; the accountable actor is the team that approved auto-remediation thresholds and validated the rollback path. Best practice is evolving for agentic workflows, but the ownership principle is stable: automation may trigger, draft, and route actions, yet humans remain responsible for policy quality, approval rules, and business impact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight are central to who owns automated security decisions. |
| NIST AI RMF | GOVERN | AI-style automated decisions still need traceable accountability and oversight. |
| OWASP Agentic AI Top 10 | Agentic workflows can create or modify pull requests with delegated execution. | |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege helps ensure bots can act without becoming the policy owner. |
| MITRE ATLAS | AML.T0058 | Automated code or workflow actions can be influenced by malicious inputs or data. |
Assign control ownership and review authority before automating merge blocks or remediation actions.
Related resources from NHI Mgmt Group
- How should security teams govern AI agents that can read tickets and open pull requests?
- When should security teams avoid automated approval for access requests?
- Should organisations allow pull_request_target for automated dependency workflows?
- How can security teams make just-in-time access work for automated workflows?
