Request Policy

What a request policy controls

A request policy sits in front of access and action requests, turning broad permission into a governed entry point. It defines which subjects can ask, what they can ask for, and the conditions that make a request eligible for approval or evaluation.

In practice, request policy is the pre-authorization layer that separates a request from a grant. It can enforce role checks, contextual checks, time windows, and risk thresholds before any approver, workflow, or automation is allowed to proceed.

Why request policy matters in IAM and NHI governance

Request policy is important because many access failures begin before a privilege is issued, not after. If policy is weak, users or systems can request too much, too often, or without enough context for safe review, which increases approval noise and weakens least-privilege enforcement.

For non-human identities, the same idea helps prevent uncontrolled creation of service access, overbroad machine access, and requests that bypass ownership or workload context. That makes request policy a governance control as much as an access control, because it shapes the demand pipeline that feeds provisioning.

What request policy usually evaluates

A well-formed request policy typically evaluates who is asking, what resource or action is being requested, why the request is needed, and whether the request matches the subject’s role, environment, or operating conditions. In mature IAM programs, this can include approver requirements, justification fields, expiry limits, and segregation-of-duties checks.

It may also use risk signals from context, such as location, device posture, sensitivity of the target system, or whether the request is unusual for that requester. The stronger the policy, the more it reduces subjective approval and replaces it with repeatable eligibility rules.

How request policy differs from approval and entitlement

Request policy is not the same as approval logic. Approval decides whether a specific request is accepted, while request policy decides whether the request is even valid enough to reach that stage and what metadata must accompany it.

It also differs from entitlement design. Entitlements define what exists to be granted, while request policy governs the path a subject must follow to ask for those entitlements or actions. That distinction matters when organisations want to control not just access, but the conditions under which access can be sought.

Risk and Threat Considerations

Weak request policy creates a predictable attack surface, because overly permissive request paths make it easier to obtain access that should have been screened, constrained, or time-limited. Poorly designed request rules can also normalise exception handling, which makes risky approvals harder to spot and easier to repeat.

Failure mechanism: Attackers and careless insiders exploit vague eligibility rules, weak justification requirements, or missing context checks to convert a request into an approval path with minimal resistance.

Impact: The result can be privilege creep, unauthorized access, faster abuse of privileged workflows, and reduced confidence that approved access actually matches business need.

Practitioner Guidance

Governance implication: Treat request policy as a policy-engineering problem, not just a workflow setting. The best policies are explicit about requester type, target sensitivity, approval thresholds, and expiry conditions, so reviewers are making exceptions less often and decisions more consistently.

What to watch for: Watch for broad catch-all request paths, missing expiry on granted access, and policies that rely on human review to compensate for vague eligibility rules. Those patterns usually indicate the request policy is not constraining demand tightly enough.

Related resources from NHI Mgmt Group

• What breaks when network controls are used instead of request-level policy for machine access?
• Who should approve changes to endpoint exposure and request policy?
• Why do AI gateways need identity, policy, and observability attached to every request?
• Who is accountable for keeping authorization approvals current when policy changes after a request is submitted?