Yes. Separation of duties should apply to AI-generated controls just as it does to human-created ones. The person who describes the need should not be the only person who can publish the resulting rule or flow, especially when the object affects verification or monitoring decisions.
Why This Matters for Security Teams
Separating AI configuration creation from publication rights is a control about blast radius, not bureaucracy. AI-generated rules, prompts, evaluations, and monitoring logic can alter verification outcomes, routing decisions, and escalation paths, so the person who drafts the logic should not be the only one who can activate it. That principle aligns with the NIST Cybersecurity Framework 2.0 emphasis on governance and access control, and it is increasingly relevant as organisations operationalise agentic workflows.
The risk is amplified when configuration is created with AI assistance. A generated rule can look plausible while embedding a faulty threshold, a hidden exception, or a broad allow condition that is difficult to notice in review. NHIMG has repeatedly documented how AI-related compromise often starts with credential abuse and rapid operationalisation, including the LLMjacking research and the DeepSeek breach coverage. In practice, many security teams encounter mispublished AI logic only after an overbroad rule has already changed monitoring, rather than through intentional review.
How It Works in Practice
Practitioners should treat AI configuration as a governed artifact with a lifecycle: draft, test, review, approve, publish, and monitor. The key control is not whether AI helped create the configuration, but whether publication requires a second set of human approvals with different responsibilities. That separation can be enforced in source control, policy engines, CI/CD gates, or platform admin workflows.
For operational consistency, teams usually pair separation of duties with change traceability and environment scoping:
- Drafting rights allow creation in a non-production workspace only.
- Publication rights require an independent reviewer or approver.
- High-risk changes, such as monitoring suppressions or detection thresholds, require heightened review.
- All published artifacts should be versioned, signed, and attributable to a human approver.
This is especially important when AI outputs are used to modify verification, alerting, or access logic. A generated configuration may be syntactically valid but operationally unsafe if it broadens trust, suppresses alerts, or creates a silent failure path. Current guidance suggests treating these changes like privileged security changes rather than routine content updates. The NIST framework helps anchor the governance expectation, while the secrets-management findings in The State of Secrets in AppSec show how quickly weak controls and fragmented oversight become persistent exposure.
These controls tend to break down in fast-moving environments where AI-generated changes are pushed directly into managed platforms without a human approval gate because the platform treats configuration edits as low-risk operational maintenance.
Common Variations and Edge Cases
Tighter publication controls often increase delivery friction, requiring organisations to balance speed against assurance. That tradeoff is real, especially in teams that iterate on detections, agent instructions, or policy logic multiple times per day.
There is no universal standard for this yet, but best practice is evolving toward risk-tiered separation. Low-impact changes may be published by the same team under standard review, while high-impact changes should require independent approval or a production release gate. For agentic ai systems, this matters even more because a single configuration can influence tool use, escalation behaviour, or downstream automation. In those cases, the control should cover not just the prompt or rule text, but any configuration that changes what the system is allowed to decide, verify, or suppress.
Edge cases include emergency hotfixes, machine-generated detection tuning, and delegated platform administration. Even then, organisations should preserve auditability and post-change review. The control objective is to ensure that no single individual can both shape the logic and unilaterally make it authoritative. Where organisations use shared service accounts or weak role boundaries, the separation becomes superficial and should be treated as incomplete governance rather than real segregation of duties.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Addresses unsafe autonomous changes and weak oversight in agentic workflows. |
| CSA MAESTRO | GOV-02 | Covers governance and approval controls for agentic AI lifecycle changes. |
| NIST AI RMF | Supports governance, accountability, and human oversight for AI-enabled decisions. |
Assign accountable approvers and document review gates for AI-generated configuration before publication.
