Cost Harvesting is the abuse of an AI service to generate unnecessary compute, token, or inference spend. Attackers do this by forcing long outputs, repeated retries, or excessive requests. Defenders should cap usage, set quotas, enforce authentication, and alert on unusual spend patterns or request volume.
What Cost Harvesting Means in AI Systems
Cost harvesting is not just noisy usage, it is an abuse pattern that turns AI compute into a target. The attacker’s objective is to make the service spend more on tokens, inference, retries, or background processing than the value of the request justifies.
This matters because AI services often bill on variable usage, so abuse can create direct financial loss even when no data is stolen. The pattern is especially relevant in systems that expose paid model access, delegated workflows, or usage-based API endpoints.
How Cost Harvesting Works
The abuse usually relies on scale and waste. A small number of prompts can be turned into disproportionate spend by forcing long generations, triggering repeated retries, chaining many calls, or sending request volumes that look legitimate individually but become expensive in aggregate.
It can also exploit product design. If a service accepts unbounded output length, weak retry logic, or expensive fallback paths, the attacker does not need deep access to create cost pressure. The service itself becomes the resource being consumed.
Why Cost Harvesting Is Operationally Dangerous
The main danger is that spend growth can outpace normal detection. Because the traffic may resemble routine user activity, teams may notice the bill spike before they notice the abuse pattern. That makes cost harvesting both a financial and a service-stability problem.
It can also distort capacity planning and budgeting. A team may respond by throttling legitimate users, tightening quotas too late, or absorbing recurring overages that mask deeper abuse controls. In that sense, cost harvesting is a governance issue as much as a security issue.
Detection, Controls, and Response
Defenders should watch for unusual request volume, repeated failed or retried calls, abnormal output sizes, and spend that diverges from normal user or application baselines. Usage telemetry should be tied to identity, workload, or tenant so that expensive patterns can be attributed and contained quickly.
Authentication, quotas, rate limits, output caps, and budget alerts are the core controls because they reduce the attacker’s ability to convert access into open-ended spend. The same monitoring should also distinguish expected batch activity from abuse so that controls do not become blunt instruments.
Risk and Threat Considerations
Cost harvesting creates a direct financial-exposure risk and can become a denial-of-wallet pattern when repeated at scale. The abuse is dangerous because the attacker does not need to break the model, only to induce expensive behavior that the service will honor.
Failure mechanism: Unbounded generations, weak retry handling, and high-volume requests allow an attacker to multiply inference and token spend faster than defenders can distinguish it from normal usage.
Impact: Organisations can face unexpected cloud or model bills, degraded service availability, budget exhaustion, and delayed detection of related abuse patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | Cost harvesting is expensive request abuse that maps to excess API resource use. |
| Recommendation — Cap request volume and output size to prevent runaway consumption. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Usage anomalies and spend spikes require review of audit and telemetry data. |
| Recommendation — Correlate usage logs with spend alerts to detect abnormal consumption patterns. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Rate limiting, monitoring, and external exposure controls help contain abusive request traffic. |
| Recommendation — Apply traffic and exposure controls that limit abusive request volume. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | Cost harvesting is identified through continuous monitoring of request and usage patterns. |
| Recommendation — Monitor model usage baselines so abnormal consumption is detected quickly. | ||
Practitioner Guidance
What to watch for: Treat cost controls as a security boundary, not just a FinOps preference. The most useful signal is not only total spend, but spend per identity, tenant, workflow, or request class, because that is what reveals whether usage is proportional to legitimate business activity.
Governance implication: Set ownership for quota policy, exception handling, and alert response before the first overage event. A service that can generate unlimited inference spend without a clear owner will usually fail open under pressure.
Related resources from NHI Mgmt Group
- What is the difference between secure identity optimisation and simple cost cutting?
- How can organisations reduce AI cost without slowing adoption?
- Why does vendor access usually cost more to secure than employee access?
- What should teams do when a low-cost remote access product lacks vendor controls?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org