Who should own authorization policy for workflow systems: IAM, app teams, or platform teams?

Ownership should be shared, but policy governance should sit with identity and security teams. App and platform teams can implement the integration, yet they should not invent their own permission rules per workflow. Central ownership reduces inconsistent approvals and keeps access decisions aligned to enterprise control requirements.

Why This Matters for Security Teams

Workflow systems blur the line between application logic and access control. If IAM, platform, and app teams each define their own rules, the result is usually inconsistent approvals, unclear accountability, and permissions that drift from enterprise policy. That is especially risky for workflows that trigger secrets use, service account actions, or downstream tool calls. NIST’s NIST Cybersecurity Framework 2.0 treats governance and access control as core security functions, not optional implementation details.

NHIMG research shows why this matters operationally: 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts, which makes decentralised permission design even harder to defend. The better model is shared ownership with central policy governance, because access decisions must stay consistent across workflows rather than be reinvented by each delivery team. In practice, many security teams discover policy drift only after a workflow has already been granted broad access and started chaining actions across systems.

How It Works in Practice

The most workable split is simple: identity and security own the authorization policy standard, while app and platform teams implement the enforcement points and integration patterns. That means IAM defines who may approve, what attributes matter, how exceptions are handled, and how policy is reviewed. Platform teams wire the controls into orchestration layers, API gateways, and workload identity systems. App teams map workflow events to the policy inputs, but they should not create bespoke permission logic per workflow.

For workflow systems, this usually means policy-as-code evaluated at runtime rather than static role assignment. Current guidance suggests using context-aware authorization signals such as environment, task type, tenant, risk score, and workload identity. When paired with NIST Cybersecurity Framework 2.0, that approach gives the organisation a repeatable control model instead of ad hoc approvals. NHIMG’s Top 10 NHI Issues highlights why this matters: unmanaged service account sprawl and excessive privilege often begin with local exceptions that later become permanent.

A practical operating model looks like this:

• IAM defines policy intent, control objectives, and approval thresholds.
• Platform teams integrate policy engines into workflow runtimes and enforcement points.
• App teams declare required actions and resource scopes, not custom entitlement rules.
• Security reviews exceptions, monitors drift, and revokes access that no longer matches policy.

That split is strongest when workflow execution is backed by workload identity, short-lived credentials, and centrally logged decisioning. It breaks down when a platform team is asked to improvise authorization inside application code, because local logic quickly becomes inconsistent across services and environments.

Common Variations and Edge Cases

Tighter central control often increases coordination overhead, so organisations have to balance consistency against delivery speed. That tradeoff becomes visible in low-code tooling, legacy workflow engines, and highly autonomous agent workflows where teams want rapid experimentation. Best practice is evolving here, but the current guidance still favours central policy ownership with delegated implementation, not delegated policy creation.

One common exception is a narrowly scoped application-specific rule that is still derived from enterprise policy and reviewed by IAM. Another is emergency access for incident response, where time-bound exceptions may be acceptable if they are logged, approved, and automatically revoked. The important distinction is that exceptions should be temporary and governed, not embedded as permanent app-team policy.

NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference for aligning authorization with lifecycle controls, while the Ultimate Guide to NHIs — Regulatory and Audit Perspectives reinforces why ownership, evidence, and revocation duties need to be unambiguous. In practice, the model fails when teams treat workflow permissions as a local engineering detail because auditors, incident responders, and security leaders then inherit a control system no one actually owns.

Related resources from NHI Mgmt Group

• Why do DNS retirements create governance risk for IAM and platform teams?
• How should IAM teams handle systems that are outside their identity governance tools?
• Why do headless systems increase governance risk for IAM and NHI teams?
• Why do event-driven systems create identity governance problems for IAM teams?