Plain-language requesting lets users describe the access they need in everyday terms instead of exact entitlement names or portal field labels. The system then translates that intent into candidate applications or resources, which lowers friction while keeping the final access decision inside governed workflow controls.
Expanded Definition
Plain-language requesting is a governed access intake pattern where a person asks for what they need in everyday language, and the system maps that request to candidate applications, data sets, or operational resources. It is most useful where entitlement names, platform labels, and service catalog codes are too technical for end users to navigate confidently. The concept sits between usability and control: the request becomes easier to express, but the approval, entitlement resolution, and provisioning logic still need to stay inside policy-backed workflow. This aligns with the broader direction of NIST Cybersecurity Framework 2.0, even though no single standard governs plain-language requesting yet. Usage in the industry is still evolving, especially where AI is used to interpret intent and suggest candidates. NHIMG treats the term as an access orchestration capability, not a shortcut around identity governance, RBAC, or PAM controls. The most common misapplication is treating natural-language input as an approval decision, which occurs when organizations let the request text directly trigger provisioning without policy validation.
Examples and Use Cases
Implementing plain-language requesting rigorously often introduces a translation and review burden, requiring organisations to balance faster self-service against the risk of ambiguous or overbroad access requests.
- A developer types “I need read-only access to the payments logs for debugging” and the system maps that intent to the approved observability role, then routes it through JIT review rather than granting direct resource access.
- A data analyst asks for “the customer retention dashboard” and the workflow resolves the request to a governed BI application package with dataset-specific entitlements.
- An operations engineer requests “temporary access to the Kubernetes deployment console” and the platform suggests the least-privilege candidate role, then enforces approval and expiration controls.
- An organization uses intent parsing to reduce catalog complexity after reviewing patterns similar to those discussed in DeepSeek breach, where excessive exposure and poor control boundaries amplified downstream risk.
- Teams compare this pattern with identity guidance in NIST Cybersecurity Framework 2.0 to keep the request experience simple while preserving control evidence.
Why It Matters in NHI Security
Plain-language requesting matters because NHI environments often grow faster than the people operating them can memorize entitlement names, which leads to shadow access, duplicate approvals, and requests that are either denied unnecessarily or granted too broadly. It can reduce help desk friction, but only if intent translation is paired with asset classification, policy checks, and auditable decisioning. This becomes especially important when secrets, service accounts, and agent-driven workflows are in play, because the wrong candidate mapping can expose privileged APIs or operational tooling. NHIMG research shows that only 44% of developers are reported to follow security best practices for secrets management, a gap that makes any ambiguous access path more dangerous when requests are converted into real credentials or tokens. In practice, the control question is not whether users can describe what they need, but whether the system can safely determine what that means. Organisations typically encounter the operational cost of plain-language requesting only after a bad entitlement match, at which point request translation becomes an unavoidable forensic and governance issue.
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 SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Plain-language request mapping can create entitlement sprawl if candidate access is not tightly governed. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access workflows must validate who is requesting access and what they are allowed to receive. |
| NIST SP 800-63 | AAL2 | Higher assurance is needed when natural-language requests can lead to privileged access outcomes. |
| NIST Zero Trust (SP 800-207) | RA | Zero trust requires continuous evaluation of access requests rather than trust in user phrasing. |
| OWASP Agentic AI Top 10 | LLM-03 | AI-assisted request interpretation can misclassify intent and must be bounded against unsafe actions. |
Constrain intent-to-entitlement translation with least-privilege policy checks before any provisioning occurs.
Related resources from NHI Mgmt Group
- What breaks when AI builds monitoring rules from plain language?
- Why do plain-language prompt injections remain the hardest to detect in production agents?
- Why should identity teams be cautious about natural-language queries over access data?
- Why does broad NHI language create risk for IAM programmes?
