ai newsSa., 17. Okt.
Eilmeldung7 mistakes AI coding agents make in Next.js + Supabase apps (and the rules that stop them)

Anthropic's 100 Overcharge Bug: What Internationalization Failures Reveal About Agent Payment Pipelines

A Costa Rican developer tried to load $100 in API credits on Anthropic's console. The platform charged $10,000 instead. The root cause was a missing decimal separator validation layer that silently interpreted "100,00" (Spanish locale format) as 10000. No confirmation modal. No server-side normaliz

dev.toSamstag 12:05 · 17.10.4 Min. Lesezeit

Posted on Oct 17 • Originally published at mech.app

A Costa Rican developer tried to load $100 in API credits on Anthropic's console. The platform charged $10,000 instead. The root cause was a missing decimal separator validation layer that silently interpreted "100,00" (Spanish locale format) as 10000. No confirmation modal. No server-side normalization. Just an instant charge 100 times larger than intended.

This is not a UX annoyance. It is a structural failure in the payment authorization boundary that sits between agent consumption metering and financial settlement. Every agent platform that bills for API calls faces this exact problem: how do you validate currency input across locales without trusting client-side formatting?

Agent platforms have two distinct flows that must intersect cleanly:

The bug occurred in the credit loading flow. Here is what failed:

The result: a $10,000 charge with no opportunity to cancel.

There are three places to handle locale-aware currency input. Each has trade-offs.

Anthropic's flow skipped steps 1, 2, and 3.

Agent platforms need two types of spending controls:

Pre-authorization limits: Maximum amount a user can load in a single transaction without manual review.

Post-authorization caps: Maximum API spend per hour/day/month to prevent runaway agent loops from draining credits.

The Anthropic incident exposed a missing pre-authorization boundary. Even if the user had intended to load $10,000, a well-designed system would require:

Here is a minimal server-side validation layer:

from decimal import Decimal, InvalidOperation from typing import Tuple def parse_currency_input ( raw_input: str, expected_locale: str, max_amount: Decimal = Decimal ( " 1000.00 " ) ) -> Tuple [ Decimal, list [ str ]]: """ Parse currency input with locale awareness and validation. Returns (parsed_amount, errors). """ errors = [] # Normalize common locale formats if expected_locale. startswith ( " es " ): # Spanish: 1.234,56 -> 1234.56 normalized = raw_input. replace ( ".

", "" ). replace ( ", ", ". " ) else: # English: 1,234.56 -> 1234.56 normalized = raw_input. replace ( ", ", "" ) try: amount = Decimal ( normalized ) except InvalidOperation: errors. append ( f " Invalid number format: { raw_input } " ) return Decimal ( " 0 " ), errors # Validation checks if amount <= 0: errors. append ( " Amount must be positive " ) if amount > max_amount: errors. append ( f " Amount exceeds maximum: { max_amount } " ) if amount. as_tuple (). exponent < - 2: errors. append ( " Maximum 2 decimal places allowed " ) return amount, errors Enter fullscreen mode Exit fullscreen mode This is not production-ready (you need proper locale libraries like Babel), but it shows the validation surface. The key insight: never trust raw user input for financial amounts.

Always parse, normalize, and validate server-side before touching a payment API.

When a payment pipeline fails, you need telemetry that answers:

Structured logging for payment events should capture:

{ "event": "credit_load_initiated", "user_id": "usr_abc123", "raw_input": "100,00", "detected_locale": "es-CR", "parsed_amount": 10000.00, "currency": "USD", "confirmation_shown": false, "payment_processor_response": { "charge_id": "ch_xyz789", "amount_charged": 10000.00 } } Enter fullscreen mode Exit fullscreen mode This log would have immediately revealed the locale parsing failure. Without it, the incident looks like user error instead of a systemic validation gap.

Beyond locale parsing, agent billing infrastructure has several high-risk surfaces:

Runaway agent loops: An agent enters an infinite retry loop, burning through credits in minutes. Mitigation: per-minute spend caps, circuit breakers on repeated identical API calls.

Stale credit balances: Agent checks balance, starts a long-running task, balance depletes mid-execution. Mitigation: reserve credits at task start, release on completion or timeout.

Currency conversion drift: User loads credits in EUR, agent API bills in USD, exchange rate changes between authorization and settlement. Mitigation: lock exchange rate at authorization time, show final USD amount before charging.

Chargeback abuse: User loads $1,000, consumes $900 in API calls, initiates chargeback. Mitigation: delayed credit availability for new accounts, fraud scoring on large initial loads.

Refund timing: User requests refund, but credits are already partially consumed. Mitigation: track consumed vs. available credits separately, only refund the unused portion.

Use locale-aware payment pipelines when:

The Anthropic incident is a case study in missing defense layers. The fix is not complicated: parse input server-side using the user's declared locale, show a confirmation modal with the final amount, and reject transactions that exceed reasonable bounds. Every agent platform that handles payments needs these three controls. Without them, a misplaced comma becomes a $10,000 mistake.

Quelle: dev.to (dev.to). Original öffnen