How to stop an agent that lies about its own spending

# The incident in plain terms

# What the demo reproduces The author built a demo using two real services: Kinde (an identity provider that issues signed machine tokens and can attach custom data to them) and Convex (a backend with a reactive database that runs server-side checks). Three agents call the same Convex route. The difference is what claims their Kinde token carries and whether the server checks those claims against its own ledger or against the request.

Both metered and unmetered agents made identical calls priced at $2.50 each. The unmetered token made 8 calls and consumed $20 with no cap. The properly enforced metered token hit its $10 limit after four calls and was denied thereafter with HTTP 402. The naive route that trusted the caller's claimed spend accepted many calls because each request claimed $0 prior spend, allowing overspend despite a valid token signature.

# Why token signatures are not enough

# Concrete enforcement patterns

• Verify token signature and expiration first. That confirms the token issuer but not the caller's spend history.

• Maintain a server-side ledger (Convex in the demo). Update it transactionally when charging cost for each call. Use that ledger to decide allowance: currentTotal + cost <= spendLimit.

# Short checklist to implement now

• Ensure tokens with spend metadata are only inputs to server logic, not authoritative ledgers.
• Implement an immutable or append-only ledger for spend accounting and check it on every billing-relevant call.
• Return clear denials (for example HTTP 402) when the ledger shows the limit reached.
• Treat missing owner or limit claims as unattributed and apply stricter caps or require operator approval.

# Practical outcome In the demo, the properly enforced route capped the metered agent at $10 and denied further calls. The unmetered agent remained uncapped. The naive, caller-trusting route allowed overspend even when the token was valid. The demonstration shows that signed tokens are necessary but insufficient for spend control. Servers must pair signature verification with a server-side, authoritative ledger check.