Who should approve write access to collaboration platform workflows?

Why This Matters for Security Teams

write access to collaboration platform workflows is not just a product permission. It is a control point that can create users, change roles, modify groups, and alter the approval path itself. That means the wrong approver can turn a routine workflow change into a governance bypass. Security teams often underestimate this because workflow builders usually know the tool, but not the downstream identity and audit impact. Guidance from the OWASP Non-Human Identity Top 10 reinforces that control over identities and secrets must be treated as a privileged function, not a convenience setting.

NHIMG research shows how quickly collaboration systems become exposure points: in The State of Secrets Sprawl 2025, 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence were classified as highly critical or urgent. That is the practical reason approval should sit with the system owner and the identity control owner. One protects business use, the other protects access governance. In practice, many security teams discover this only after a workflow has already widened access or exposed an audit gap, rather than through intentional review.

How It Works in Practice

The approval model should distinguish between who builds a workflow and who is accountable for the access outcomes it can produce. The workflow builder may propose the change, but the system owner should confirm business need and intended use, while the identity control owner should confirm least privilege, role boundaries, and auditability. This is especially important when the workflow can create users, update groups, assign roles, or trigger downstream provisioning. A practical review usually includes three checks:

• Scope check: what access can the workflow create, change, or remove?
• Governance check: does the change align with existing RBAC, approval chains, and joiner-mover-leaver rules?
• Evidence check: can the change be traced back to a named business need and a named approver?

This is also where Ultimate Guide to NHIs is directly relevant. NHI controls are not only about service accounts and API keys; they also cover the systems and automation that can alter identity state. In environments with heavy automation, approval should be tied to identity governance ownership, not just application administration. The OWASP Non-Human Identity Top 10 is useful here because it frames excessive privilege and poor lifecycle control as structural risks, not one-time mistakes. Current best practice is to require dual approval for any workflow permission that can affect identities or access groups, then log the approval context, scope, and rollback path. These controls tend to break down when the platform lets builders self-approve changes or when identity ownership is split across teams with no single accountable approver.

Common Variations and Edge Cases

Tighter approval control often increases delivery time, so organisations have to balance governance strength against workflow speed. That tradeoff matters most in fast-moving SaaS environments where teams expect self-service automation and rapid iteration.

There is no universal standard for this yet, but current guidance suggests a few exceptions should be handled carefully. Low-risk read-only workflow changes may be approved by the system owner alone if they cannot alter identity state. Conversely, any workflow touching provisioning, group membership, privilege escalation, or cross-system triggers should usually require both the system owner and identity control owner. Where a platform supports delegated administration, that delegation should be time-bound, documented, and reviewable.

Another edge case is shared ownership. If the system owner sits in operations and the identity control owner sits in security, the approval record should still show a single decision path, not a vague consensus. That prevents gaps when something needs to be reversed later. NHIMG’s 52 NHI Breaches Analysis is a reminder that weak ownership boundaries are a recurring failure mode, especially when automation expands faster than governance.

Where collaboration workflows can invoke provisioning APIs, SCIM, or directory admin actions, approval should be treated as privileged access approval, not ordinary app change management. That distinction breaks down in legacy ticketing models where requestors and approvers are the same operational group, because the reviewer lacks independence over identity impact.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• Why do collaboration tools create such a large secrets risk?
• When do NHI access reviews create more value than a one-time cleanup?