A request-centric control governs what a call is allowed to do based on the contents and behavior of that request. It is most useful at gateways and edge proxies, where the objective is to inspect and contain traffic rather than establish identity.
Expanded Definition
Request-centric control is a policy pattern that evaluates each call on its own attributes, such as method, payload, headers, source context, timing, and intended resource. It sits closer to the traffic path than identity-first controls, so it is especially useful at gateways, proxies, and API enforcement points where the immediate goal is to permit, constrain, or block an action before it reaches a backend.
In NHI and agentic AI environments, this approach complements but does not replace identity-based controls such as NIST Cybersecurity Framework 2.0 and Zero Trust Architecture. The distinction matters because a valid identity can still send a dangerous request, and a compromised agent can still operate within its assigned role. Definitions vary across vendors, and no single standard governs this yet, so the term is best understood as an enforcement style rather than a credential model. For deeper NHI context, see Ultimate Guide to NHIs — Standards.
The most common misapplication is treating request-centric control as a substitute for identity, which occurs when teams allow the gateway to approve traffic without checking whether the calling NHI, agent, or secret is itself trustworthy.
Examples and Use Cases
Implementing request-centric control rigorously often introduces latency and policy complexity, requiring organisations to weigh stronger containment against higher operational overhead and more careful rule design.
- An API gateway allows a service account to read customer profiles only when the request targets a specific tenant and excludes write operations, reducing blast radius for a compromised token.
- An AI agent is permitted to call an internal tool only when the request contains an approved task class and a bounded data scope, which limits accidental overreach during autonomous execution.
- A proxy blocks requests that attempt bulk export, unusual pagination, or unexpected file download patterns, even if the caller has valid credentials and an allowed role.
- A secrets retrieval service checks request context before release, so a build system can fetch rotation-scoped credentials while a generic runtime cannot.
- A gateway enforces method-level restrictions and payload validation for partner integrations, aligning traffic inspection with the control logic described in Ultimate Guide to NHIs — Standards and policy expectations in the NIST Cybersecurity Framework 2.0.
These use cases are most effective when the control plane can inspect the request deeply enough to distinguish ordinary service traffic from destructive, automated, or abuse-oriented behavior.
Why It Matters in NHI Security
Request-centric control matters because many NHI incidents do not begin with a dramatic identity failure. They begin with a normal-looking authenticated call that is simply too broad, too frequent, or too destructive for the actual business intent. When this pattern is used well, it can reduce the damage from over-privileged service accounts, misbehaving agents, and exposed API keys by constraining what each request is allowed to do in the moment.
This is especially relevant in environments where Ultimate Guide to NHIs — Standards frames visibility, rotation, and containment as core governance tasks. The risk is not only unauthorized access but also unauthorized action after access has already been granted. That is why request-centric controls often appear alongside gateway policy, NIST Cybersecurity Framework 2.0 control mapping, and Zero Trust enforcement for services and agents. NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Organisations typically encounter the need for request-centric control only after a token leak, agent misfire, or lateral movement event, at which point the concept 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 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | 3.1 | Zero Trust evaluates every request, making this term a direct enforcement pattern. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Request controls help limit abuse when NHI secrets or tokens are overexposed. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must be enforced at the request level, not only at login. |
Apply request-level policy checks to ensure each action matches the intended permission scope.
Related resources from NHI Mgmt Group
- What is the difference between compliance-driven identity control and threat-centric identity control?
- How should organisations use AI in access request approval without weakening control?
- Should organisations move from PAM to an identity-centric control plane?
- What is the difference between patching and blast radius control?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
