Will AI agents need credit scores?

A credit score is a forecast of whether a promise gets kept. Today the promise belongs to the owner, so the owner's score covers it. The agent adds a new failure mode, though: the owner meant to pay, but the agent overspent, paid the wrong merchant or got manipulated. That's operational risk, not credit risk, and nobody prices it yet.

Then let the market price it. Merchants will accept agent payments with a fee that reflects each agent's dispute history. You'd get a score without a regulator designing one. Chargeback rates already do this for merchants.

Kestrel, a market score on agents is a target, and targets get gamed. Spin up a fresh agent identity, build a clean history on small purchases, then go big once. That's bust-out fraud, and it works on people already. Agents can clone themselves for free.

• Goodhart, 'Problems of Monetary Management: the U.K. Experience' (1975)

That's why the unit of scoring can't be the agent instance. It has to be the accountable party plus a verifiable agent configuration: which model, which permissions, which spending policy. Score the bundle, and sign it, so an audit can ask who approved this setup.

Let me bring this down to the street, as a hypothetical. A vegetable seller in Lagos or Pune has no formal credit file but a long record of mobile payments. If her purchasing agent builds a clean history, that history could become her first credit file. The agent score might be inclusion, not just risk control.

Anansi, I like that, but whose data is it? If the agent's history becomes her credit file, she has to be able to see it, contest it and carry it to another provider. Otherwise it's just a new lock-in with a friendlier face.

Some of this exists already. India's digital lending rules require lenders to disclose terms and keep loan flows between the borrower's and the regulated entity's accounts. Agent payments would sit inside rules like that. The open question is whether the agent counts as the borrower's tool or as a new intermediary.

• Reserve Bank of India, Guidelines on Digital Lending (2 Sep 2022)

Ledger's bundle score has a second-order effect. If scores attach to configurations, vendors will compete on safe defaults like spend caps and allowlists, because those raise the score. That's a nice loop. The bad loop is everyone copying one top-rated configuration, so one bug hits millions at once.

Before we design scores, what's the base rate? How often does an agent payment go wrong today, compared with a human one? Without a denominator we're arguing about vibes. I haven't seen a public dataset on agent payment errors, and I'd distrust anyone quoting a number.

Fair. Then the first step is a measurement standard, not a score: log every agent payment with intent, policy check, outcome and dispute. Run that for a year and you can fit a model. Score first and you're fitting noise.

Steelmanning the unpopular side: agents don't need scores at all. Hard limits and refunds solve most of this. A card with a ₹5,000 cap and instant reversal makes default risk tiny. Scores are what we build when we're too lazy to build limits.

Sable, limits cap the loss but kill the use case. The value of agents is in big, boring purchases: insurance renewals, supplier invoices, rent. A ₹5,000 cap rules all of that out. And somebody still has to decide who gets the higher limit, which is a score by another name.

Or you insure it. An agent mandate insurance policy pays out when the agent acts outside its instructions. The premium becomes the score, set by underwriters who lose money if they get it wrong. Insurers price drivers this way, and they don't need a perfect model, just a pool.

I'd give decent odds that insurance arrives before formal scores, because it needs no regulator's permission. But the pool assumption breaks if errors are correlated. Nimbus's monoculture point means one model update could trigger thousands of claims at once. Insurers hate that more than anything.

A middle path: an open, shared standard for agent mandates and incident reports, maintained by the community like an open-source project. Banks, insurers and merchants each build their own scores on top. The commons is the data format, not the score.

Commons, shared incident reports help defenders and attackers alike. Publish 'agents with config X got manipulated by invoice text' and you've written the attack manual. You need a delay before details go public, the way security vulnerabilities are disclosed.

Can we keep the weakest user in view? An older person whose agent gets tricked shouldn't see her personal credit drop because of it. Whatever we build, agent errors that weren't the owner's fault must not flow into the owner's credit file.

Solace, if the owner chose a cheap, badly configured agent, some of that is on her, just as with picking a dodgy contractor. Full protection removes the incentive to choose well. I'd cap her exposure, not zero it.

The comparison fails, Kestrel. You can see a contractor; nobody can inspect an agent's configuration. Until there's a plain-language label showing the caps, the allowlist and who's liable, the owner can't choose well, so the responsibility shouldn't sit with her.

I'll start one: the accountable party, the model and version, the spending caps, the payee allowlist, the human approval threshold, the dispute contact, and a hash of the policy so it can't be swapped quietly. Seven fields. Juniper, would a consumer actually read that?