Anthropic Extra Usage Spend Limit Deleted

Extra usage spend limits cap Anthropic organizational spend beyond included usage. Deleting a spend limit removes that cap and can enable unrestricted API or Claude consumption. An attacker who already has administrative or API access can delete the limit to burn budget, run large automated workloads, or stage resource abuse without the previous guardrail.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/09/16"
  3integration = ["anthropic"]
  4maturity = "production"
  5updated_date = "2026/09/21"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Extra usage spend limits cap Anthropic organizational spend beyond included usage. Deleting a spend limit removes that
 11cap and can enable unrestricted API or Claude consumption. An attacker who already has administrative or API access can
 12delete the limit to burn budget, run large automated workloads, or stage resource abuse without the previous guardrail.
 13"""
 14false_positives = [
 15    """
 16    Finance or platform teams delete outdated spend limits when consolidating billing policies or replacing them with
 17    new limits. Confirm the actor, nearby create or update events, and an approved change before escalating.
 18    """,
 19]
 20from = "now-9m"
 21language = "esql"
 22license = "Elastic License v2"
 23name = "Anthropic Extra Usage Spend Limit Deleted"
 24note = """## Triage and analysis
 25
 26### Investigating Anthropic Extra Usage Spend Limit Deleted
 27
 28Deleting an extra-usage spend limit removes a billing guardrail; it does not create spend by itself. Treat it as an
 29early signal for follow-on quota burn or automated workloads.
 30
 31Unauthorized = no finance/platform ticket to redesign billing, and no nearby `extra_usage_spend_limit_created` /
 32`extra_usage_spend_limit_updated` that replaces the deleted limit — especially if high chat creation or file uploads
 33follow.
 34
 35#### Possible investigation steps
 36
 37- Branch on actor: `user_actor` → `user.email` / `source.ip` / UA; `api_actor` → `anthropic.audit.actor.api_key_id`
 38  and whether that key is in inventory.
 39- Check for create/update of a replacement limit within the same change window (planned redesign) vs standalone
 40  deletion.
 41- After the delete, look for elevated `claude_chat_created`, file uploads, or other high-volume activity on the same
 42  `organization.id`.
 43- Close as FP when a finance/platform ticket names the redesign and a replacement create/update exists. Escalate when
 44  deletion is orphaned or usage spikes afterward.
 45
 46### False positive analysis
 47
 48- Billing consolidations often delete an old limit shortly before creating a new one.
 49
 50### Response and remediation
 51
 52- On unauthorized deletion: restore an appropriate spend limit, review API keys and admin sessions active during the
 53  exposure window, and quantify extra usage accrued after the change.
 54"""
 55references = ["https://platform.claude.com/docs/en/api/compliance/activities/list"]
 56risk_score = 47
 57rule_id = "9a944f66-417d-4dee-83a2-afd3f7980212"
 58severity = "medium"
 59tags = [
 60    "Domain: GenAI",
 61    "Platform: Anthropic",
 62    "Data Source: Anthropic Audit Logs",
 63    "Use Case: Threat Detection",
 64    "Resources: Investigation Guide",
 65    "Rule Type: ES|QL",
 66    "Tactic: Impact",
 67]
 68timestamp_override = "event.ingested"
 69type = "esql"
 70
 71query = '''
 72from logs-anthropic.audit-* metadata _id, _version, _index
 73| where
 74    data_stream.dataset == "anthropic.audit" and
 75    mv_contains(event.category, "configuration") and
 76    event.action == "extra_usage_spend_limit_deleted"
 77| keep _id, _version, _index, @timestamp, event.*, organization.*, user.*, source.*, user_agent.*, anthropic.audit.*, data_stream.*
 78'''
 79
 80
 81[[rule.threat]]
 82framework = "MITRE ATT&CK"
 83[[rule.threat.technique]]
 84id = "T1496"
 85name = "Resource Hijacking"
 86reference = "https://attack.mitre.org/techniques/T1496/"
 87
 88
 89[rule.threat.tactic]
 90id = "TA0040"
 91name = "Impact"
 92reference = "https://attack.mitre.org/tactics/TA0040/"
 93
 94[rule.investigation_fields]
 95field_names = [
 96    "@timestamp",
 97    "event.action",
 98    "event.id",
 99    "organization.id",
100    "anthropic.audit.spend_limit_id",
101    "anthropic.audit.actor.type",
102    "anthropic.audit.actor.api_key_id",
103    "user.email",
104    "user.id",
105    "source.ip",
106    "user_agent.original",
107]

Triage and analysis

Investigating Anthropic Extra Usage Spend Limit Deleted

Deleting an extra-usage spend limit removes a billing guardrail; it does not create spend by itself. Treat it as an early signal for follow-on quota burn or automated workloads.

Unauthorized = no finance/platform ticket to redesign billing, and no nearby extra_usage_spend_limit_created / extra_usage_spend_limit_updated that replaces the deleted limit — especially if high chat creation or file uploads follow.

Possible investigation steps

  • Branch on actor: user_actor → user.email / source.ip / UA; api_actor → anthropic.audit.actor.api_key_id and whether that key is in inventory.
  • Check for create/update of a replacement limit within the same change window (planned redesign) vs standalone deletion.
  • After the delete, look for elevated claude_chat_created, file uploads, or other high-volume activity on the same organization.id.
  • Close as FP when a finance/platform ticket names the redesign and a replacement create/update exists. Escalate when deletion is orphaned or usage spikes afterward.

False positive analysis

  • Billing consolidations often delete an old limit shortly before creating a new one.

Response and remediation

  • On unauthorized deletion: restore an appropriate spend limit, review API keys and admin sessions active during the exposure window, and quantify extra usage accrued after the change.

References

Related rules

to-top