A design approach that treats authorization as part of the developer workflow rather than a late-stage security add-on. It aims to remove friction by making access decisions clear, reusable, testable, and easy to review, so teams can build features faster without scattering permission logic through application code.
Expanded Definition
Workflow-first authorization is a design discipline that places access control inside the engineering process itself, so permission rules are written, reviewed, and tested with the same rigor as application logic. In NHI and IAM programs, that means authorization decisions are expressed in reusable policy layers or code-adjacent controls rather than scattered across endpoints, scripts, and manual exceptions. The approach is closely aligned with least privilege, but it is not identical to it: least privilege describes the outcome, while workflow-first authorization describes how teams build and maintain the control.
This pattern is especially useful when developers need to evolve products quickly without losing clarity over who or what can perform an action. It also supports separation of duties because policy changes can be reviewed independently of feature code. Definitions vary across vendors, and no single standard governs this yet, so the practical meaning often depends on whether a team uses policy-as-code, centralized authorization services, or framework-enforced guardrails. NIST guidance on access control, including NIST SP 800-53 Rev 5 Security and Privacy Controls, provides the broader control foundation that this approach operationalizes. The most common misapplication is treating workflow-first authorization as a UI convenience layer, which occurs when teams validate permissions only at the front end and leave backend enforcement inconsistent.
Examples and Use Cases
Implementing workflow-first authorization rigorously often introduces process discipline and review overhead, requiring organisations to weigh development speed against stronger, more auditable access control.
- A platform team stores service-to-service permissions in a policy repository so application changes can be reviewed alongside the code that depends on them.
- A CI/CD pipeline runs authorization tests before deployment to confirm that new API routes do not expose actions to unauthorized NHIs.
- An engineering team uses a centralized policy engine so developers can request access changes through the same workflow used for feature approvals.
- A security reviewer traces a privilege change from pull request to runtime enforcement, which makes permission drift easier to detect during audits.
- After a secrets exposure, teams examine how GitHub Action tj-actions Supply Chain Attack style failures can spread when authorization logic is hidden in scripts rather than governed through the workflow.
For the control plane behind these examples, NIST guidance on access enforcement and accountability remains relevant, especially when teams need authorization decisions to be consistent across services, environments, and automated agents.
Why It Matters in NHI Security
Workflow-first authorization matters because NHIs fail in ways that human-centric access models often miss. Service accounts, API keys, CI/CD tokens, and agent credentials can gain access through code paths that are hard to audit after the fact. NHIMG research shows that 97% of NHIs carry excessive privileges, which means the absence of workflow-native authorization often turns small implementation shortcuts into broad exposure. When permissions are reviewable and testable in the developer workflow, teams are more likely to catch privilege creep before it reaches production.
This also improves governance around secrets, delegation, and automated execution. In practice, it helps prevent the pattern where a temporary integration becomes a permanent entitlement because no one re-examines the access rule during delivery. It is especially important for agentic systems, where an AI agent may invoke tools or APIs faster than a human reviewer can trace the effect. The security value is not just cleaner code; it is better containment when an identity is compromised or misused. Organisations typically encounter the operational cost of weak authorization only after a secrets leak, at which point workflow-first authorization becomes unavoidable to contain lateral access and prove what should have been allowed.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret and access handling that workflow-first authorization helps prevent. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions management and least-privilege enforcement across systems. |
| NIST Zero Trust (SP 800-207) | AC-6 | Zero Trust requires explicit, continuous authorization decisions for each access attempt. |
| NIST SP 800-63 | AAL2 | Assurance concepts inform how strongly identities must be bound before access is granted. |
| OWASP Agentic AI Top 10 | A01 | Agentic systems need governed tool access and approval paths to avoid unsafe execution. |
Build reviewable, testable authorization paths so NHI access does not rely on scattered code checks.
Related resources from NHI Mgmt Group
- Should organisations use DLP or authorization first for AI agents?
- Should organisations use scanners or policy engines first when fixing authorization sprawl?
- What breaks when authorization happens inside the LLM prompt instead of the workflow?
- Who is accountable when a workflow can change authorization policy?
