The practice of setting policy around how expensive a request may be, based on endpoint semantics, parameter ranges, and expected business use. It shifts control design from raw traffic limits to a more precise model of safe application behaviour.
Expanded Definition
Request-cost governance is a policy approach for API and application control that evaluates the relative expense of a request before it is accepted or executed. Cost is not only compute time. It can also reflect database load, expensive joins, model inference, external service calls, fan-out to downstream systems, or business-sensitive actions triggered by a single input. This makes the concept broader than rate limiting, which counts requests without understanding their likely impact.
In practice, request cost is usually inferred from endpoint semantics, parameter ranges, authentication context, and expected business use. A low-frequency request can still be high risk if it triggers a burst of backend work or exposes a privileged workflow. Guidance varies across vendors because no single standard governs this yet, but the design intent aligns closely with the control emphasis in the NIST Cybersecurity Framework 2.0, where governance and protective controls should match business impact.
The most common misapplication is treating request-cost governance as a simple replacement for rate limits, which occurs when teams block volume but ignore expensive parameters, recursive calls, and workflow abuse.
Examples and Use Cases
Implementing request-cost governance rigorously often introduces policy complexity, requiring organisations to weigh precision and safety against tuning effort and potential friction for legitimate users.
- A search endpoint assigns higher cost to queries with broad wildcards, deep pagination, or multiple sort operations because those patterns amplify backend load.
- An AI-powered support API charges more policy cost to requests that force long-context retrieval, multi-step tool use, or repeated LLM calls.
- An e-commerce platform marks refund or payout actions as high-cost because a single request can trigger identity checks, fraud scoring, ledger writes, and notifications.
- A data export endpoint applies stricter approval or throttling when a request targets large date ranges, many fields, or sensitive records.
- An internal administration API evaluates caller role, tenant scope, and parameter combinations to prevent low-volume abuse that bypasses generic traffic thresholds.
For identity-heavy systems, request cost can also become a proxy for abuse resistance when privileged operations are exposed to service accounts or automation. That is especially relevant in environments using Non-Human Identity controls, where a single machine credential can execute a high-impact action without looking noisy in traditional monitoring.
Why It Matters for Security Teams
Security teams need request-cost governance because many application attacks do not depend on high request counts. They depend on making the system do expensive work on demand. That can lead to denial of service, resource exhaustion, cost inflation, privilege abuse, and hidden backend pressure that standard traffic controls miss. The governance model is particularly useful when applications expose complex search, orchestration, or agentic workflows, because those functions often have very uneven execution cost.
The identity connection matters when the request originates from a service identity, API key, or autonomous AI Agent. In those cases, the caller may be authenticated but still not trustworthy for every action or parameter combination. Request-cost governance helps separate “is this caller allowed?” from “is this request reasonable to process?” That distinction is central to modern application security and increasingly relevant to NHI governance, where a credential can be valid while the workload it drives remains unsafe.
Organisations typically encounter request-cost governance only after a low-volume abuse event, a runaway integration, or an agentic workflow causes unexpected spend or service degradation, at which point the control becomes operationally unavoidable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO | Defines governance practices that set policy for acceptable system behaviour and risk. |
| NIST AI RMF | GOVERN | Govern function covers AI system oversight where costly model requests create operational risk. |
| OWASP Agentic AI Top 10 | Addresses agentic abuse patterns where individual actions can be disproportionately expensive. | |
| OWASP Non-Human Identity Top 10 | Covers machine identities whose valid credentials can still drive unsafe or costly requests. | |
| NIST SP 800-63 | AAL2 | Identity assurance helps determine when stronger controls are needed for sensitive requests. |
Increase request scrutiny for higher-assurance actions and do not treat authentication alone as sufficient.
