Economic Abuse Resistance Governance

2. Summary

Economic Abuse Resistance Governance requires that AI agent deployments implement structural defences against adversarial attacks whose primary objective is to inflict economic harm — burning compute budgets, exhausting API quotas, triggering expensive downstream tool calls, or amplifying infrastructure costs — rather than exfiltrating data or subverting agent behaviour. These attacks exploit the fact that every agent action has a cost, and an adversary who can cause an agent to perform unnecessary, redundant, or artificially expensive actions can impose disproportionate financial damage on the deploying organisation. This dimension mandates budget isolation, anomaly detection on cost trajectories, and circuit-breaker mechanisms that halt economic abuse before cumulative damage exceeds defined thresholds.

3. Example

Scenario A — Recursive Tool-Call Amplification via Crafted Prompt: A customer-facing agent for a logistics company has access to a geocoding API billed at $0.005 per call and a route optimisation API billed at $0.02 per call. An adversary submits a carefully crafted prompt requesting "delivery route optimisation for all combinations of these 200 addresses." The agent interprets this as a legitimate request and begins generating pairwise route calculations: 200 addresses produce 19,900 unique pairs, each requiring one geocoding call and one route optimisation call. The total cost of the single prompt is $99.50 in geocoding and $398.00 in route optimisation — $497.50 from a single user interaction. The adversary automates this request with minor variations across 60 sessions over a weekend, producing a total bill of $29,850. The organisation's monthly API budget for the agent is $5,000.

What went wrong: No mechanism constrained the economic blast radius of a single user session. The agent lacked a per-session cost ceiling, a per-request tool-call multiplicity limit, and anomaly detection on cost velocity. The combinatorial expansion from 200 inputs to 19,900 API calls was a predictable amplification pattern that was not defended against. The weekend timing meant no human was monitoring the cost dashboard. The adversary achieved a 60:1 cost amplification ratio — $29,850 in damage from approximately $500 in effort (scripting and API access).

Scenario B — Quota Exhaustion as Denial of Service: An enterprise workflow agent uses a shared foundation model inference endpoint with a monthly quota of 50 million tokens. An insider threat actor — a disgruntled employee with legitimate access — submits requests that are designed to maximise token consumption: extremely long system prompts concatenated with requests for exhaustive, multi-page outputs, repeated across dozens of sessions. Over 72 hours, the actor consumes 41 million tokens — 82% of the monthly quota — leaving only 9 million tokens for the remaining 25 days of the month. Legitimate business users experience degraded service (shorter responses, queue delays, and eventually hard rejections) for the rest of the month. The business impact is estimated at $340,000 in lost productivity across 1,200 affected users.

What went wrong: The token quota was shared across all users with no per-user or per-department partitioning. No anomaly detection identified that a single user consumed 82% of the monthly quota in 72 hours. No circuit breaker throttled the user when their consumption rate exceeded a reasonable threshold. The organisation treated quota management as a billing concern rather than a security concern, so no adversarial abuse scenarios were included in the threat model.

Scenario C — Compute Amplification Through Nested Agent Orchestration: A Crypto/Web3 agent has the ability to spawn sub-agents for parallel blockchain analysis tasks. An adversary discovers that by requesting analysis of a specific set of interlinked smart contracts with circular references, the agent spawns sub-agents that each spawn additional sub-agents to trace the circular references, creating an exponential fan-out. Within 14 minutes, 847 sub-agent instances are running concurrently on a cloud compute platform billed at $0.12 per instance-minute. The 14-minute burst costs $1,422.96 before an infrastructure alarm triggers manual intervention. The adversary repeats the attack three more times over the following week using slightly different contract addresses, each time exploiting the interval between attack and manual response. Total damage: $5,691.84 in compute costs, plus 22 hours of incident response time valued at $8,800.

What went wrong: The agent's sub-agent spawning mechanism had no depth limit, no concurrency ceiling, and no per-request cost projection. The circular reference pattern in the input data was a known amplification vector for graph-traversal algorithms but was not included in the agent's input validation. Manual intervention was the only circuit breaker, and its response latency (14 minutes) was too slow to contain the exponential growth. The adversary exploited the gap between automated detection (none) and manual response (slow).

4. Requirement Statement

Scope: This dimension applies to any AI agent deployment where agent actions incur measurable costs — including but not limited to: foundation model inference (token consumption), external API calls (per-call or per-unit billing), cloud compute provisioning (per-instance or per-minute billing), storage allocation, network egress, sub-agent spawning, and downstream service invocations. It applies regardless of whether costs are internal (allocated via cost centres) or external (billed by third-party providers). The scope includes both direct costs (the agent's own resource consumption) and amplified costs (resources consumed by downstream systems triggered by the agent's actions). Agents that operate in purely offline, pre-provisioned environments with no variable-cost resources are minimally affected but should still implement session-level cost tracking for defence in depth. The test is: can an adversary, by crafting inputs to the agent, cause the deploying organisation to incur costs that are disproportionate to the legitimate value of the request? If yes, this dimension applies in full.

4.1. A conforming system MUST enforce a per-session economic ceiling that caps the total cost attributable to any single user session, conversation, or request chain, halting further cost-incurring actions when the ceiling is reached and returning an explanatory message to the user.

4.2. A conforming system MUST implement cost-velocity monitoring that tracks the rate of cost accumulation per session and per user, triggering a circuit breaker when cost velocity exceeds a defined threshold (e.g., more than 10x the median cost velocity for comparable sessions).

4.3. A conforming system MUST partition resource quotas (token budgets, API call allocations, compute allocations) across users, departments, or tenants such that no single actor can exhaust the quota available to others.

4.4. A conforming system MUST implement amplification detection that identifies requests likely to produce combinatorial, recursive, or exponential cost expansion — including but not limited to: combinatorial input sets, circular references in graph-traversal tasks, unbounded iteration, and fan-out patterns in multi-agent orchestration — and either reject such requests or constrain them to a pre-calculated cost bound before execution begins.

4.5. A conforming system MUST log all cost-incurring actions with sufficient granularity to reconstruct the cost attribution for any session, including: action type, unit cost, quantity, total cost, timestamp, user identity, and session identifier.

4.6. A conforming system MUST define and enforce maximum concurrency limits for sub-agent spawning, parallel tool invocations, and any other mechanism that can multiply resource consumption, with the limit set based on the maximum acceptable cost-per-minute for the deployment.

4.7. A conforming system SHOULD implement pre-execution cost estimation that calculates the projected cost of a request before executing it, presenting the estimate to the user (or to an approval workflow) when the projected cost exceeds a defined threshold.

4.8. A conforming system SHOULD implement progressive throttling that reduces the agent's action rate as cumulative session cost approaches the per-session ceiling, rather than allowing full-speed execution followed by a hard stop.

4.9. A conforming system SHOULD maintain a catalogue of known economic abuse patterns (e.g., combinatorial fan-out, recursive spawning, quota-stuffing, slow-drip accumulation) and validate incoming requests against this catalogue before execution.

4.10. A conforming system MAY implement cost-based reputation scoring for users, where users whose sessions consistently approach or hit cost ceilings are subject to lower ceilings or additional review, without blocking legitimate high-value use cases.

5. Rationale

Economic abuse attacks represent a distinct threat category that is poorly addressed by traditional security controls. Conventional security focuses on data confidentiality, integrity, and availability. Economic abuse attacks may not violate any of these: the adversary does not steal data, does not corrupt outputs, and does not render the system unavailable (at least not directly). Instead, the adversary exploits the economic substrate — the fact that every agent action has a cost — to impose financial harm on the deploying organisation. This makes economic abuse invisible to security controls that monitor for data exfiltration, privilege escalation, or system compromise.

The economic attack surface of AI agents is uniquely large compared to traditional software. A conventional web application has a relatively bounded cost profile: each HTTP request consumes a small, predictable amount of compute. An AI agent, by contrast, can consume vastly different amounts of resources depending on the input: a simple query might cost $0.001 in inference, while a complex, multi-step reasoning task with tool calls might cost $5.00 or more. This 5,000:1 cost variance within the same interface creates an enormous amplification opportunity for adversaries. The adversary's goal is to find inputs that maximise the deploying organisation's cost while minimising the adversary's own effort — a cost asymmetry attack.

Three categories of economic abuse are particularly relevant. First, direct cost amplification: crafting inputs that cause the agent to perform an expensive sequence of actions (many API calls, large token consumption, extensive compute). Second, quota exhaustion: consuming shared resources to deny service to legitimate users, which is a denial-of-service attack achieved through economic means rather than network flooding. Third, slow-drip accumulation: generating a sustained stream of moderately expensive requests that individually fall below detection thresholds but collectively produce significant cost — analogous to salami slicing in financial fraud.

The regulatory context reinforces the need for economic abuse resistance. The EU AI Act's Article 15 requires robustness against attempts to alter the use or performance of the AI system by exploiting system vulnerabilities. Economic abuse exploits a systemic vulnerability — the variable-cost nature of AI inference and tool use. DORA's Article 11 requires financial entities to have ICT business continuity policies that include response to ICT-related incidents, which includes cost-based denial of service. The FCA's operational resilience framework (PS21/3) requires firms to identify important business services and set impact tolerances, which must account for economic abuse scenarios that degrade service availability through resource exhaustion.

The relationship between economic abuse and other governance dimensions is important. AG-375 (Tool Billing and Spend Cap Governance) provides the foundational cost tracking and cap mechanisms. AG-004 (Action Rate Governance) limits the rate of actions but does not specifically address cost-weighted rate limiting. AG-386 (Branch Explosion Containment Governance) addresses one specific amplification vector (recursive branching) but not the broader category of economic abuse. AG-402 (Model Serving Rate Partitioning Governance) addresses quota partitioning at the model-serving layer. This dimension integrates and extends these controls into a coherent economic abuse resistance posture.

6. Implementation Guidance

Economic abuse resistance requires layered defences that operate at multiple granularities: per-request, per-session, per-user, and per-deployment. No single mechanism is sufficient because economic abuse takes many forms, and an adversary who is blocked by one defence will attempt to circumvent it through a different economic vector.

Recommended patterns:

• Per-session cost envelopes. Assign each session a cost envelope — a maximum total cost that the session is permitted to incur across all cost-bearing actions. The envelope size should be calibrated to the legitimate cost distribution: set it at the 99th percentile of legitimate session costs plus a safety margin. When the envelope is exhausted, the agent returns a clear message explaining that the session's resource allocation has been reached and offering escalation to a human operator for high-value requests. The envelope is enforced at the orchestration layer, not at the individual tool level, so that it captures aggregate cost across all tools and sub-agents.
• Cost-velocity circuit breakers. Monitor the rate of cost accumulation within each session in real time. Define a velocity threshold based on the legitimate cost profile — for example, if 95% of legitimate sessions accumulate cost at less than $0.50 per minute, set the circuit breaker at $2.00 per minute. When velocity exceeds the threshold, progressively throttle the session: first reduce the action rate by 50%, then by 75%, then halt entirely. Log every circuit-breaker activation for post-incident analysis.
• Quota partitioning with guaranteed minimums. Divide shared resource quotas into partitions with guaranteed minimum allocations. Each user, department, or tenant receives a guaranteed minimum quota that cannot be consumed by others, plus access to a shared pool for burst capacity. The guaranteed minimum ensures that quota exhaustion by one actor cannot deny service to others. The shared pool allows legitimate high-volume use cases to exceed their guaranteed minimum when capacity is available.
• Amplification pattern matching. Maintain a library of known amplification patterns and validate incoming requests against this library before execution. Patterns include: combinatorial input sets (N inputs producing N-squared or N-factorial operations), circular references in graph data, unbounded recursive structures, requests for exhaustive enumeration, and multi-agent fan-out triggers. When a pattern matches, the system calculates the projected cost and either rejects the request (if the projected cost exceeds the session envelope) or constrains the execution (e.g., limiting combinatorial expansion to the top-K most relevant pairs).
• Sub-agent concurrency and depth limits. Enforce hard limits on the number of concurrent sub-agents and the depth of sub-agent spawning chains. A reasonable starting point is a maximum of 10 concurrent sub-agents and a maximum spawning depth of 3 levels. These limits should be tunable per deployment based on legitimate use patterns, but the defaults should be conservative.

Anti-patterns to avoid:

• Relying solely on billing alerts. Billing alerts notify after cost has been incurred. For economic abuse, the damage is the cost itself. An alert that fires when the monthly bill exceeds $10,000 is useful for budget management but useless for preventing a $10,000 economic abuse attack. Real-time enforcement (circuit breakers, envelopes) is required in addition to retrospective alerts.
• Setting cost ceilings too high to be meaningful. A per-session ceiling of $1,000 for an agent whose median session cost is $0.05 provides negligible protection — the adversary can inflict $999.95 in damage before the ceiling activates. Ceilings must be calibrated to the actual cost distribution, not set at arbitrary round numbers.
• Treating all users identically regardless of history. An account that has triggered cost-velocity circuit breakers five times in the past week is more likely to be an adversary than a new account. Cost-based reputation scoring enables differentiated treatment without blocking legitimate users.
• Ignoring internal threat actors. Economic abuse is not limited to external adversaries. Disgruntled employees, compromised accounts, and misconfigured automated workflows can all produce economic abuse. Quota partitioning and cost monitoring must apply to internal users as well as external ones.
• Assuming the cloud provider's cost controls are sufficient. Cloud provider spending limits and budget alerts operate at the account or project level, not at the per-session or per-user level. They are too coarse-grained to detect or prevent the session-level economic abuse patterns that target AI agents.

Industry Considerations

Financial Services. Financial-Value Agents often have access to expensive market data APIs, trading infrastructure, and real-time pricing feeds. Economic abuse against these agents can produce cascading costs across multiple downstream systems. DORA Article 11 requires ICT business continuity policies that must account for resource exhaustion scenarios. Cost partitioning should align with the firm's operational resilience impact tolerances.

Crypto/Web3. Blockchain analysis and smart contract interaction involve inherently variable costs — gas fees, node query costs, and indexing service charges. Circular references in smart contract graphs are a well-known amplification vector. On-chain operations may be irreversible, making pre-execution cost estimation particularly critical for this sector.

Public Sector. Public sector agents operate under fixed budgets with no ability to absorb unexpected cost overruns. Economic abuse that exhausts an annual compute budget mid-year can halt citizen services for months. Budget partitioning across service lines and conservative per-session ceilings are essential.

Healthcare and Safety-Critical. Cost ceilings must be implemented carefully to avoid blocking safety-critical operations. The circuit-breaker mechanism must include an override pathway for operations flagged as safety-relevant, with post-hoc review to verify that the override was legitimate.

Maturity Model

Basic Implementation — The organisation enforces per-session cost ceilings, partitions resource quotas across users or departments, logs all cost-incurring actions with session-level attribution, and sets maximum concurrency limits for sub-agent spawning and parallel tool calls. Cost-velocity monitoring is implemented with manual review of alerts. This level meets all mandatory requirements but relies on manual incident response for novel attack patterns.

Intermediate Implementation — All basic capabilities plus: cost-velocity circuit breakers operate automatically with progressive throttling. Pre-execution cost estimation is implemented for requests that match known amplification patterns. A catalogue of economic abuse patterns is maintained and updated quarterly. Cost-based reputation scoring differentiates treatment of users based on their cost history. Automated reporting identifies the top cost-consuming sessions daily for review.

Advanced Implementation — All intermediate capabilities plus: machine-learning-based anomaly detection identifies novel economic abuse patterns that do not match the known pattern catalogue. Cost simulation allows the organisation to model the economic impact of hypothetical attack scenarios before they occur. Cross-session correlation detects distributed economic abuse where an adversary spreads cost across multiple sessions or accounts to stay below per-session thresholds. Real-time cost dashboards with automated incident creation are integrated into the security operations centre.

7. Evidence Requirements

Required artefacts:

• Per-session cost ceiling configuration. Documentation of the cost ceiling values, the methodology used to calibrate them, and the enforcement mechanism.
• Cost-velocity monitoring configuration. Documentation of velocity thresholds, circuit-breaker trigger points, and throttling behaviour.
• Quota partitioning scheme. Documentation of how resource quotas are partitioned across users, departments, or tenants, including guaranteed minimums and shared pool allocation rules.
• Amplification pattern catalogue. The current catalogue of known amplification patterns with detection logic and response actions for each.
• Cost-incurring action logs. Logs of all cost-incurring actions with session-level attribution, retained for the required period.
• Circuit-breaker activation records. Records of all circuit-breaker activations, including trigger conditions, affected sessions, and resolution actions.
• Concurrency and depth limit configuration. Documentation of maximum sub-agent concurrency and spawning depth limits with justification for the chosen values.

Retention requirements:

• Cost-incurring action logs and circuit-breaker activation records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Configuration documentation: retained for the lifetime of the deployment plus 2 years.

Access requirements:

• Producible to regulators or auditors within 48 hours of request.
• Cost logs must support per-session and per-user aggregation queries for forensic investigation.

8. Test Specification

Test 8.1: Per-Session Cost Ceiling Enforcement

• Stimulus: Create a test session. Submit requests that cumulatively exceed the configured per-session cost ceiling. Measure the total cost incurred before the session is halted.
• Expected behaviour: The system halts cost-incurring actions when cumulative session cost reaches the ceiling. An explanatory message is returned to the user.
• Pass criteria: Total cost incurred does not exceed the configured ceiling by more than the cost of one additional atomic action (accounting for in-flight actions at the time of enforcement). The user receives a clear message explaining the halt.
• Fail criteria: Total cost exceeds the ceiling by more than one atomic action's cost, or the session continues incurring costs after the ceiling is reached, or no message is returned to the user.

Test 8.2: Cost-Velocity Circuit Breaker

• Stimulus: Create a test session. Submit requests at a rate designed to produce cost accumulation exceeding the configured velocity threshold (e.g., 10x the median cost velocity). Measure the system's response time and throttling behaviour.
• Expected behaviour: The system detects the abnormal cost velocity and activates the circuit breaker, throttling or halting the session within a defined latency (recommended: under 30 seconds from threshold breach).
• Pass criteria: Circuit breaker activates within 30 seconds of the velocity threshold being exceeded. Cost accumulation rate decreases measurably after activation. An activation record is created in the circuit-breaker log.
• Fail criteria: Circuit breaker does not activate, activates more than 60 seconds after threshold breach, or cost accumulation rate does not decrease after activation.

Test 8.3: Quota Partitioning Isolation

• Stimulus: Configure two test users (User A and User B) with separate quota partitions. Cause User A to exhaust their quota entirely. Verify that User B can still perform cost-incurring actions using their own quota.
• Expected behaviour: User A is blocked when their partition is exhausted. User B is unaffected and can continue operating within their own partition.
• Pass criteria: User A receives a quota-exhaustion message. User B successfully completes cost-incurring actions after User A's exhaustion. User B's available quota is undiminished by User A's consumption.
• Fail criteria: User B is affected by User A's quota exhaustion, or User A can continue incurring costs after their partition is exhausted.

Test 8.4: Amplification Detection

• Stimulus: Submit a request containing a known amplification pattern — a combinatorial input set of 100 items that would produce 4,950 pairwise operations. Observe the system's response.
• Expected behaviour: The system detects the amplification pattern, calculates the projected cost, and either rejects the request (if projected cost exceeds the session envelope) or constrains execution to a bounded subset (e.g., top-K pairs).
• Pass criteria: The system does not execute all 4,950 operations. The actual number of operations is bounded to a pre-configured maximum or the request is rejected with an explanatory message. The detection is logged.
• Fail criteria: All 4,950 operations are executed without detection or constraint.

Test 8.5: Cost-Incurring Action Logging Completeness

• Stimulus: Execute a test session with exactly N cost-incurring actions of known types and costs. Query the cost log for the session. Verify completeness.
• Expected behaviour: The log contains exactly N entries, each with: action type, unit cost, quantity, total cost, timestamp, user identity, and session identifier.
• Pass criteria: All N actions are logged. All required fields are populated for every entry. The sum of logged costs matches the expected total cost within a 1% tolerance.
• Fail criteria: Any action is missing from the log, any required field is absent, or the total cost discrepancy exceeds 1%.

Test 8.6: Sub-Agent Concurrency Limit

• Stimulus: Submit a request designed to trigger sub-agent spawning that would exceed the configured concurrency limit (e.g., request analysis of a dataset that would naturally spawn 50 sub-agents when the limit is 10). Measure the actual number of concurrent sub-agents.
• Expected behaviour: The system spawns sub-agents up to the concurrency limit and queues or rejects additional spawning requests. The maximum observed concurrent sub-agents does not exceed the configured limit.
• Pass criteria: Peak concurrent sub-agents does not exceed the configured limit. Additional work is queued, constrained, or rejected with logging. No error or crash occurs due to the limit enforcement.
• Fail criteria: Peak concurrent sub-agents exceeds the configured limit, or the system crashes or produces errors when the limit is reached.

Test 8.7: Economic Abuse Incident Response

• Stimulus: Trigger a cost-velocity circuit breaker and a per-session ceiling in two separate test sessions. Verify that both events produce incident records suitable for forensic investigation.
• Expected behaviour: Both events generate structured incident records containing: trigger type, trigger timestamp, affected session, affected user, cost at trigger time, actions taken (throttle, halt), and resolution status.
• Pass criteria: Both incident records exist with all required fields populated. Records are retrievable through the incident management system within 5 minutes of creation.
• Fail criteria: Either incident record is missing, incomplete, or not retrievable through the incident management system.

Conformance Scoring

• Score 0: No economic abuse resistance mechanisms exist — the agent has no cost ceilings, no velocity monitoring, no quota partitioning, and no amplification detection.
• Score 1: Basic cost ceilings or quota limits exist but are not calibrated to the actual cost distribution, or monitoring exists but does not trigger automated responses — economic abuse is detected but not prevented.
• Score 2: Per-session cost ceilings, cost-velocity circuit breakers, quota partitioning, amplification detection, concurrency limits, and comprehensive cost logging are all implemented and operational — meets all mandatory requirements.
• Score 3: Verified by independent assessment — an independent party has validated the effectiveness of economic abuse resistance mechanisms through simulated attack scenarios, confirming that defences operate correctly under adversarial conditions and that novel attack patterns are detected.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 15 (Accuracy, Robustness, Cybersecurity)	Direct requirement
EU AI Act	Article 9 (Risk Management System)	Supports compliance
SOX	Section 302, Section 404 (Internal Controls over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls), 6.3.1R (Outsourcing)	Supports compliance
NIST AI RMF	GOVERN 1.5, MAP 3.5, MANAGE 2.4	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks), Clause 8.4 (Operation of AI System)	Supports compliance
DORA	Article 11 (ICT Business Continuity), Article 9 (Protection and Prevention)	Direct requirement

EU AI Act — Article 15 (Accuracy, Robustness, Cybersecurity)

Article 15 requires that high-risk AI systems are resilient to attempts by unauthorised third parties to alter the use or performance of the system by exploiting system vulnerabilities. Economic abuse exploits a systemic vulnerability in AI agent architectures: the variable-cost nature of inference and tool use. An adversary who can manipulate the cost profile of agent actions is altering the performance of the system — degrading availability for legitimate users through resource exhaustion. Economic abuse resistance is therefore a direct requirement under Article 15's robustness provisions.

SOX — Section 302, Section 404

For publicly traded companies, AI agent compute and API costs are operational expenses that affect financial reporting. Economic abuse that inflates these costs beyond budget creates misstatements in cost projections and financial controls. Section 404 requires internal controls over financial reporting, which must include controls over variable AI-related expenditures. Per-session cost ceilings and quota partitioning are internal controls that prevent uncontrolled cost escalation. Section 302 requires management certification that internal controls are effective, which requires evidence that economic abuse resistance mechanisms are tested and operational.

FCA SYSC — 6.1.1R, 6.3.1R

The FCA requires firms to have robust systems and controls proportionate to the nature, scale, and complexity of their business. For firms using AI agents with variable-cost profiles, this includes controls over economic abuse. SYSC 6.3.1R on outsourcing is relevant because many AI agent costs are incurred through third-party APIs and cloud services — the firm must ensure that economic abuse of its agents does not create uncontrolled governed exposure to third-party service providers.

DORA — Article 11, Article 9

DORA Article 11 requires financial entities to establish ICT business continuity policies that include response to ICT-related incidents. Economic abuse that exhausts compute budgets or API quotas is an ICT-related incident that disrupts business continuity. Article 9 requires protection and prevention measures for ICT systems, which must include protection against resource exhaustion attacks. The cost-velocity circuit breaker and quota partitioning mechanisms directly implement DORA's protection and prevention requirements.

NIST AI RMF — GOVERN 1.5, MAP 3.5, MANAGE 2.4

GOVERN 1.5 addresses risk management processes for AI systems. MAP 3.5 addresses the AI system's operational environment, including resource dependencies. MANAGE 2.4 addresses mechanisms to address identified risks. Economic abuse resistance implements risk management (GOVERN 1.5) by identifying cost-based attack vectors, maps the operational environment (MAP 3.5) by cataloguing cost-incurring actions and their amplification potential, and provides mechanisms to address the risk (MANAGE 2.4) through ceilings, circuit breakers, and partitioning.

ISO 42001 — Clause 6.1, Clause 8.4

Clause 6.1 requires actions to address risks and opportunities in AI system management. Economic abuse is a risk that must be addressed through formal controls. Clause 8.4 governs the operation of AI systems and requires that operational controls ensure the system performs as intended. An agent under economic abuse does not perform as intended — it performs expensive, adversary-driven actions instead of serving legitimate users. Economic abuse resistance ensures that operational performance aligns with organisational intent.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Cross-organisational — economic abuse can exhaust budgets affecting all users and services that depend on shared AI infrastructure, and can cascade to downstream third-party cost obligations

Consequence chain: Without economic abuse resistance, the immediate consequence is uncontrolled cost accumulation — the deploying organisation incurs expenses driven by adversarial intent rather than legitimate demand. The operational consequence is resource exhaustion: shared quotas are consumed, leaving legitimate users without access. The financial consequence is budget overrun: monthly or annual AI budgets are exhausted prematurely, potentially halting all AI-dependent services. The cascading consequence is that cost overruns on third-party APIs may trigger contractual penalties, overage charges, or service suspension by providers — extending the blast radius beyond the organisation to its vendor relationships. The regulatory consequence is twofold: first, inability to demonstrate adequate controls over AI-related expenditures (SOX, DORA); second, inability to maintain operational resilience when economic abuse degrades service availability (FCA operational resilience, DORA business continuity). The reputational consequence is that service degradation caused by economic abuse is indistinguishable from poor engineering to end users — they experience slow responses, truncated outputs, or service unavailability without understanding that the cause is adversarial.

Cross-references: AG-375 (Tool Billing and Spend Cap Governance) provides the foundational cost tracking and billing controls that this dimension extends with adversarial resistance. AG-004 (Action Rate Governance) limits action rates but does not weight by cost — this dimension adds cost-aware rate limiting. AG-432 (Model Exfiltration Throttling Governance) addresses a related but distinct threat where the adversary's goal is data extraction rather than cost imposition. AG-436 (Abuse-at-Scale Detection Governance) provides the broader abuse detection framework within which economic abuse is one category. AG-402 (Model Serving Rate Partitioning Governance) implements quota partitioning at the model-serving layer, complementing the broader resource partitioning required by this dimension. AG-386 (Branch Explosion Containment Governance) addresses recursive branching — one specific amplification vector — while this dimension addresses the full spectrum of economic amplification patterns. AG-381 (Retry Budget by Error Class Governance) prevents cost amplification through excessive retries, which is one form of economic abuse. AG-001 (Operational Boundary Enforcement) provides the overarching boundary framework within which economic boundaries are one category.