Proposal for review: Artificial Intelligence Billing Delegation Standard for user-authorized API usage

ChatGPT Use cases and examples
, , , ,
1

Proposal for review: Artificial Intelligence Billing Delegation Standard for user-authorized API usage

I would value technical critique from OpenAI API developers, platform engineers, billing/security specialists, and anyone building consumer-facing artificial intelligence applications.

I have published an open-source draft proposal called the Artificial Intelligence Billing Delegation Standard (ABDS):

The problem I am trying to address is this:

Consumer artificial intelligence applications currently face a difficult billing model:

  1. The developer absorbs unpredictable inference/API costs.
  2. The user is forced into Bring Your Own Key flows, which ordinary consumers do not understand.
  3. Every application rebuilds its own credit system, quota tracking, usage limits, and abuse controls.

This creates friction for consumer artificial intelligence applications, especially small developers who want to build useful apps without taking on open-ended API cost exposure.

The proposal is an OAuth-style authorization model for user-authorized, provider-enforced artificial intelligence resource consumption.

At a high level:

User Subscription Entitlement
        ↓
Delegated Artificial Intelligence Grant
        ↓
Short-lived Execution Token
        ↓
Provider-side Usage Ledger

The core technical principle is:

Mutable quota state does not belong in token claims.

The execution token should reference the delegation. The provider-side grant and usage ledger should remain authoritative for quota, revocation, model scope, and abuse controls.

This is not intended as:

  • a Bring Your Own Key wrapper,

  • a request for unlimited user quota,

  • a bypass around provider billing,

  • a blockchain or credit-token proposal,

  • or a claim that OpenAI, Anthropic, Google, or any other provider is involved.

It is an open technical draft intended for review.

The current repository includes:

  • technical specification,

  • provider discovery proposal,

  • implementation profiles,

  • threat model,

  • roadmap,

  • executive/technical PDF brief,

  • AI-assisted review contributions.

The areas where I would most value feedback are:

  1. Is this better framed as an OAuth-style profile, a token-exchange profile, or something else?

  2. Is the four-object model technically sound?

  3. Should delegated usage be enforced entirely through provider-side grants and ledgers?

  4. What abuse cases would make this unsafe for a provider?

  5. How should streaming, long-running, and agentic workloads reserve and settle quota?

  6. Would this solve a real pain point for developers building consumer artificial intelligence applications?

I am not asking for support with a bug or billing issue. I am asking whether this kind of delegated billing model is technically realistic, useful, or flawed.

Github Repository name again for anyone interested in the full specifications and detail:
MJohnstonAI / ai-billing-delegation

Any critique is welcome, especially from people with experience in API platform design, OAuth, billing infrastructure, usage metering, security, or consumer AI app development.

ABDS
ABDS1672Ă—941 274 KB

2

Hey NeuroSyncAI, welcome to the community!

Thanks for sharing this. This idea is technically plausible. OAuth-style grants and short-lived execution tokens are established patterns, and avoiding mutable quota in token claims is the right way.

The believe the main challenge is abuse and incentives. Things like misleading consent, laundering high-volume traffic through users, token replay, and apps creating large costs without clear user intent.

Let’s see what the community thinks.

Avinash

3

Dear Avinash,

Really appreciate the engagement — and you’ve identified exactly the right pressure point. Abuse and incentive design is the part that determines whether this is viable, not the token mechanics.

A few things already in the spec that address the specific failure modes you raised:

Misleading consent — the consent screen requirements specify the app name, verified publisher, quota cap, period, model class, and whether overage is possible must all be disclosed in plain language before a grant is created. Unverified apps get a explicit warning at consent time.

Laundering high-volume traffic through users — this is the “quota laundering” threat in the formal threat model: a malicious app aggregates many consumer delegations and effectively resells access. Mitigation is per-client and per-user velocity limits, app verification tiers, and provider-side anomaly detection on delegated calls specifically (separate from normal rate limiting).

Token replay — execution tokens are short-lived (max 15 min in the spec), audience-restricted, carry a jti for replay detection, and the spec recommends DPoP as a risk-based hardening layer for high-quota or elevated-risk delegations rather than mandating it universally (to avoid raising the implementation bar for smaller providers).

Apps creating large costs without clear user intent — this is why the grant object itself caps per-request maximums, not just period totals, and why the spec separates “estimate/reserve/execute/settle” for variable-cost workloads like streaming or agentic loops, so a runaway tool-call loop can’t silently blow through a user’s entire delegated allowance before the provider catches it.

The honest gap right now is that none of this has been pressure-tested against real abuse patterns — it’s a threat model on paper, not validated against production traffic. If there’s a category of abuse you’re not seeing addressed, or one where the proposed mitigation looks weak in practice, I’d genuinely like to know — that’s exactly the kind of feedback the spec needs before it’s credible to anyone implementing it.

Full threat model and the rest of the spec are on GitHub — search MJohnstonAI / ai-billing-delegation (new account here so I can’t post raw links yet)

Marc Johnston
NeuroSync AI Dynamics

4

Dear Avinash — following up on the abuse/incentive point, which I have addressed in a reply, but I also think it’s worth zooming out for a second on why these matters beyond just closing security gaps.
The threat model is the harder half of this problem, no argument there. But I think it’s worth naming explicitly why solving it is worth the engineering investment, because “is this technically sound” and “is this worth building” are two different questions.

The case for implementing something like this:

Right now, a developer building a consumer AI app has three bad options: absorb the inference cost themselves, force users into BYOK flows ordinary people don’t understand, or build a custom credit system from scratch. A lot of apps that would otherwise get built simply don’t, because none of those options are good enough to justify the risk. That’s not just inconvenient for developers — it’s actively shrinking the number of AI apps that exist at all.

Whichever provider solves this first doesn’t just remove friction, they become the place where it’s easiest to build. That’s a much stickier kind of advantage than benchmark performance, because once a developer’s billing model is built around your delegation system, switching costs go up sharply. It also doesn’t require giving anything away — the provider stays the authoritative enforcer the whole time, controls which models are delegable, what counts as abuse, what plans qualify, and whether overage is even allowed. ABDS isn’t “open the vault,” it’s “build the door with a lock you control.”

The cost of not solving it:

If this stays unsolved, every developer ends up building their own version of the same workaround, which means every provider inherits the same reputational risk by proxy — users hit confusing limits or surprise costs, and they blame “AI billing” generally, often without distinguishing which provider’s API actually sits underneath the app they’re using.

There’s also a first-mover dynamic worth naming honestly: whoever ships this well first effectively sets the de facto pattern everyone else gets compared to, the same way early OAuth implementations shaped how the rest of the ecosystem ended up using it. Being second doesn’t mean catching up on quality, it means catching up on a developer base that’s already integrated against someone else’s grant model, error codes, and consent flow.

I’m not asking anyone to take this on faith — the abuse surface you raised is the real gating question, and the spec’s threat model is a first draft, not a finished answer. But I think the “is this worth solving” question and the “is this solved well enough yet” question are both worth keeping on the table at the same time, because the second one only matters if the first one is true.

Marc Johnston
NeuroSync AI Dynamics

7

Great write-up!

I'll add this to the feedback I'm compiling for the product team, along with a few additional points that have come up.

Avinash