Requestable Access

Expanded Definition

Requestable access is a privilege state in which a user or agent can request a tool, system, or dataset on demand rather than holding standing permission. In NHI programs, that distinction matters because the identity may exist continuously, but the privilege only becomes active during an approved session window. The model is often paired with JIT provisioning, approval workflows, and scoped session controls so access can be traced, limited, and revoked predictably.

Definitions vary across vendors on whether requestable access is treated as an access policy, a privilege lifecycle state, or a workflow pattern. NHI Management Group treats it as a governance pattern that sits between RBAC and JIT: RBAC decides eligibility, JIT activates access, and requestable access describes the on-demand request path that triggers that activation. The nearest standards language is found in least-privilege and zero trust guidance such as OWASP Non-Human Identity Top 10 and NIST SP 800-207 Zero Trust Architecture.

The most common misapplication is treating requestability as permission itself, which occurs when teams approve a request without enforcing a bounded session, a named approver, and a clear expiration condition.

Examples and Use Cases

Implementing requestable access rigorously often introduces approval latency and operational friction, requiring organisations to weigh faster delivery against stronger containment of privileged actions.

• A deployment bot requests temporary access to a production secrets manager only during a release window, then loses access automatically when the session ends.
• An AI agent asks for permission to query a customer support dataset, with approval limited to a single workload, time box, and read-only scope.
• A service account requests access to an internal API for incident response, but the approver grants it only after validating the incident ticket and expected command set.
• A developer tool requests elevated access to rotate certificates, while the approval path records who approved it and why, supporting later review.

These patterns become easier to govern when paired with the lifecycle and visibility practices described in the Ultimate Guide to NHIs, especially when requestable access is used to reduce persistent privilege. For implementation detail, the CISA Zero Trust Maturity Model reinforces the need to separate eligibility from active access and to log every activation event.

Why It Matters in NHI Security

Requestable access helps organisations shrink the blast radius of service accounts, bots, and agents that do not need permanent privilege. That matters because NHIs already carry disproportionate risk: NHI Management Group reports that 97% of NHIs carry excessive privileges, which broadens the attack surface when access is always on.

In practice, requestable access only works when approver ownership, session scope, and revocation are all explicit. Without those controls, the request workflow becomes a false sense of security: access is “approved,” yet still too broad, too long-lived, or too hard to audit. The same weakness appears in breach analyses where privileged identities are compromised after over-permissioned systems remain reachable longer than intended, as discussed in 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10.

Organisations typically encounter the cost of requestable access only after a token is misused during an incident, at which point bounded activation and approver traceability become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Non-Human Identity Access Management
• What is Just-in-Time (JIT) access and why is it important for NHI security?
• When is it crucial to implement least-privilege access for AI agents?
• How should security teams run access reviews for non-human identities?