Treat them like privileged control surfaces. Separate who can edit logic from who can execute it, require audit trails for every change, and define review boundaries for high-impact actions. If marketers or operators can alter outcomes in real time, the programme needs access controls, approval steps, and traceability equal to the business impact of the workflow.
Why This Matters for Security Teams
Business-controlled workflows are not ordinary application logic once they can change at runtime. They become privileged control surfaces because a non-technical owner can alter who gets access, what data is exposed, or which downstream systems are triggered without a full deployment cycle. That creates a governance problem that sits between change management, identity control, and auditability.
Security teams often misread this as a low-code administration issue. In practice, the risk is broader: runtime edits can bypass code review, weaken segregation of duties, and create invisible privilege changes inside tools that business teams trust. NIST’s NIST Cybersecurity Framework 2.0 still applies, but these workflows also need NHI-style control discipline because execution authority is the real asset. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is clear that auditability and traceability are not optional when machine-driven access affects business outcomes.
NHIMG research shows how exposed this becomes at scale: 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts in the first place. In practice, many security teams discover uncontrolled workflow changes only after an approval path, integration, or customer-facing action has already been altered in production.
How It Works in Practice
The right model is to govern the workflow as an identity-backed control plane, not just as a business tool. That means separating the person who edits logic from the person who approves its activation, and treating execution as a distinct privilege. If a workflow can send money, grant access, or write to a system of record, it should have its own accountable identity, change history, and scoped permissions.
Current guidance suggests three layers of control:
- Change authority: limit who can modify rules, prompts, branching logic, and connectors.
- Execution authority: restrict who can publish, enable, or escalate a workflow into production.
- Outcome authority: define which actions require approval, threshold checks, or dual control.
For runtime-adaptive workflows, the control set should also include versioning, immutable logs, and policy checks at execution time. That is where policy-as-code and access review intersect: the system should evaluate whether the current context, identity, and target action still match approved boundaries. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because workflow identities need lifecycle management just like service accounts, including provisioning, rotation, and offboarding. For implementation patterns, the NIST Cybersecurity Framework 2.0 supports mapping these controls into asset, access, and change governance.
Teams should also require event-level audit trails that show what changed, who changed it, what runtime inputs were present, and what downstream effect occurred. These controls tend to break down when business users can directly edit production-connected workflows in SaaS platforms that lack granular separation between configuration, approval, and execution paths.
Common Variations and Edge Cases
Tighter workflow governance often increases friction for business teams, so organisations must balance speed against the risk of uncontrolled runtime change. That tradeoff is real, especially where marketing, operations, or customer-success teams depend on rapid adjustments to campaigns, routing, or notifications.
Best practice is evolving for low-code and no-code platforms because there is no universal standard for this yet. Some environments can use lightweight approvals for low-risk edits, while high-impact workflows need stricter controls such as dual approval, break-glass access, or time-bound publish rights. The key is to classify workflows by business impact, not by whether the tool looks technical.
Edge cases arise when workflows chain multiple systems or call external APIs through shared connectors. In those cases, the workflow may inherit broad privileges from the connector itself, making the real risk hidden from the business owner. NHIMG’s Top 10 NHI Issues highlights why excessive privilege and poor visibility are recurring failure modes, while NIST’s framework reinforces that governance must cover both change and execution. The hard boundary is that once a workflow can materially alter records, access, or payments in real time, it should be treated as privileged infrastructure, not as a convenience feature.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Runtime workflow changes rely on credential control and rotation discipline. |
| NIST CSF 2.0 | PR.AC-4 | Separating edit, approve, and execute rights maps to access governance. |
| NIST AI RMF | Runtime-changing workflows need accountable governance and impact-based oversight. |
Assign owners, document impacts, and monitor runtime changes as governed AI-adjacent risk.
Related resources from NHI Mgmt Group
- How should security teams govern Microsoft-driven service workflows across Teams, Intune, and Entra?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
- How should security teams govern non-human identities in Salesforce?
