A request and approval workflow is a governance process for software installation where developers ask for access and administrators decide whether to allow it. It helps organisations preserve engineering speed while maintaining oversight, auditability, and control over risky tools, extensions, and packages on managed devices.
Expanded Definition
Request and approval workflow is the control path that determines who can obtain software, extensions, packages, or elevated access, and under what conditions. In NHI and endpoint governance, the workflow is less about convenience and more about proving that risky software is reviewed before it reaches a managed environment. The practice aligns closely with the access governance intent of the NIST Cybersecurity Framework 2.0, especially where organisations need repeatable authorisation, traceability, and exception handling.
Definitions vary across vendors on whether the workflow includes only human approval or also policy-based auto-approval, but the operational aim is consistent: reduce unvetted installs while preserving delivery speed. In NHI-heavy environments, approval decisions should account for whether a tool can read secrets, invoke APIs, or create persistent credentials. A mature workflow records the requester, business justification, security review outcome, and expiry of any exception. The most common misapplication is treating it as a procurement ticketing step, which occurs when approval is based only on convenience or manager sign-off instead of security impact.
Examples and Use Cases
Implementing request and approval workflow rigorously often introduces friction for developers, requiring organisations to weigh rapid onboarding against the cost of review, exception tracking, and enforcement.
- A developer requests a browser extension on a managed laptop; security approves only if it cannot access saved credentials or developer portals.
- An engineering team asks for a CI/CD plugin; the approver checks whether the plugin can exfiltrate API keys or modify build secrets, informed by incidents like the GitHub Action tj-actions Supply Chain Attack.
- An admin grants a time-limited exception for a package needed for incident response, with automatic revocation after the response window closes.
- A platform team uses policy to auto-approve low-risk internal packages while routing anything that touches secrets, endpoints, or service accounts to manual review.
- Approval evidence is stored for audit so that later investigations can confirm who authorised the install and why.
For broader governance context, the workflow should be mapped to enterprise identity controls described in the NIST Cybersecurity Framework 2.0 and treated as part of the software supply chain rather than a standalone help desk queue.
Why It Matters in NHI Security
Request and approval workflow matters because unmanaged software installs can become a direct path to secret exposure, privilege escalation, and persistent compromise. NHIMG reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, and 96% store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That combination makes approval gates a practical control for reducing exposure before risky tooling lands on endpoints or build systems.
In NHI security, the workflow helps determine whether a package, extension, or automation tool can access tokens, certificates, or service account material. It also creates an audit trail that supports investigations, remediation, and exception expiry. Relevant governance guidance appears in NHIMG’s Ultimate Guide to NHIs, which frames visibility and lifecycle control as essential to reducing identity risk. The control becomes especially important when software supply chain compromises are involved, because a single approved tool can cascade into secrets theft across many systems. Organisations typically encounter the urgency of request and approval workflow only after a package or extension has been abused in a breach, at which point it becomes operationally unavoidable to address.
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 governance around risky NHI-related tooling and secret exposure paths. |
| NIST CSF 2.0 | PR.AC-4 | Access approvals support least-privilege authorization and traceability. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous authorization rather than implicit trust after install. | |
| NIST SP 800-63 | IAL2 | Identity assurance informs who is allowed to request and approve access. |
| OWASP Agentic AI Top 10 | A10 | Agentic systems need controlled tool approval to limit unsafe execution paths. |
Verify approvers and requesters with sufficient assurance before granting privileged software access.
