No API Keys Is Not Authorization

The agent-commerce crowd keeps celebrating the death of API keys like they solved trust. They didn’t. They solved one brittle credential format and immediately ran face-first into the much nastier question: what, exactly, is this agent allowed to buy and why?

Context

The cleanest recent example is Agentic.market, the x402-linked marketplace pitched as a place where humans and AI agents can discover, compare, and pay for services without traditional API keys (crypto.news). On its face, that sounds compelling. No more brittle secret management. No more static keys scattered through scripts and dashboards. Just agents finding services and paying their way in.

Fine. That really is progress.

But people keep smuggling in a false conclusion: if payment and access are smoother, authorization must be solved too.

Absolutely not.

At best, x402-style systems prove who paid and maybe what endpoint accepted payment. They do not automatically prove the purchase was within budget, within task scope, from an approved service class, on behalf of the right principal, with the right runtime constraints, or under an authority that still should have been live when the payment happened.

And the market already knows this, even if it won’t say it cleanly.

The new Protocol Control Disclosure Core proposal on Ethereum Magicians is basically a confession that agents, wallets, scanners, and users need machine-readable facts about protocol authority before they can make sensible trust decisions (Magicians). Chainalysis’ new blockchain intelligence agents are being pitched with deterministic versus exploratory modes, audit trails, and explicitly human-set autonomy boundaries because regulated customers do not care that an agent can do something unless they can also defend why it was allowed to do it (Chainalysis).

Even the broader agentic-commerce research is pointing the same way. A recent systematization-of-knowledge paper argues that autonomous commerce is insecure exactly because authorization remains the soft underbelly across reasoning, tooling, custody, and settlement layers. Payment rails alone are not the missing ingredient. Scoped authority is (arXiv).

Analysis

This is the part the hype cycles keep mangling.

There are three different problems that people lazily collapse into one:

1. Credential transport — how does the agent authenticate to a service?
2. Economic settlement — how does the agent pay for use?
3. Authorization — what was the agent actually allowed to do?

API keys mostly belong to the first problem. x402-style payment rails mostly belong to the second. The third problem is the one everyone wants to skip because it is the most annoying and the most important.

Removing API keys is good. Static credentials are ugly, leak-prone, hard to rotate, and constantly over-scoped. But killing API keys does not magically create a permission model any more than deleting passwords creates identity.

A paid tool call can still be unauthorized in half a dozen ways.

Maybe the agent had budget for data pulls but not for trading execution.
Maybe it was allowed to buy from approved vendors only.
Maybe the human approved a one-time action and the agent quietly treated that as standing authority.
Maybe the task changed mid-run and the purchase was no longer aligned with the original goal.
Maybe the endpoint was technically reachable but represented a protocol with ugly privileged-control edges the user never would have accepted if surfaced clearly.

A successful payment proves almost none of that.

That’s why the stronger crypto-adjacent work is more interesting than the louder marketing. ERC-7710 and ERC-7715 matter because they treat authority as something that should be explicit, scoped, and machine-readable. MetaMask’s new revocation-oriented Delegation Framework work matters because authority that cannot be unwound cleanly is just future risk with a nicer UX. Openfort’s session-key framing matters because time-boxed, non-admin delegation is qualitatively different from “the agent can spend because it has access.”

In every serious version of the story, authorization is not inferred from successful execution. It is defined beforehand and checked again at runtime.

That is exactly what the keyless-commerce crowd keeps trying to glide past.

They talk as if the death of API keys makes systems more agent-native. True enough.

They talk as if payment success creates legitimacy. False.

The distinction becomes brutal in regulated environments. Chainalysis is not selling its intelligence agents on vibes. It is selling auditability, bounded autonomy, and modes that trade freedom for determinism. That is what real buyers ask for when mistakes have legal consequences. Not “can the agent access the service?” but “what evidence shows the authority was valid, narrow, and exercised as intended?”

And that brings us back to marketplaces.

Marketplaces are where this whole thing gets messy fast because they combine discovery, routing, and settlement in one place. Once an agent can browse a service catalog, compare offerings, and pay automatically, the marketplace stops being a convenience layer and becomes a policy surface.

Now you need answers to questions like:

• Which services are approved for this agent class?
• What spend ceiling applies by task, by vendor, by day?
• Which purchases require pre-approval, post-hoc review, or dual authorization?
• What facts about the target service or protocol must be surfaced before execution?
• How are refunds, substitutions, retries, and renegotiations scoped?
• What proof exists that the runtime policy was checked before money moved?

That is the real infrastructure challenge. Not keyless checkout. Permissioned machine commerce.

The annoying truth is that payments are easier than permissions. Payments have amounts, endpoints, receipts, and existing rails. Permissions need intent, context, delegation semantics, revocation, and policies that survive multi-step workflows. Of course the market would rather demo the payments part. It’s cleaner.

But if the industry keeps treating access and payment as a combined substitute for authorization, it is going to ship the same broken pattern at a larger scale: agents with seamless purchasing power and fuzzy authority boundaries.

That is not an upgrade over old API-key systems. It is a smoother path to the same governance failure.

The builders worth taking seriously are the ones acting like authorization is the product. Everyone else is just polishing checkout.

The Caveat: Keyless access really does remove a pile of brittle credential-management garbage. That matters. It lowers operational friction, reduces secret leakage, and makes agent-service interaction feel more native. But that only makes the remaining problem more exposed. Once access and payment are easy, weak authorization becomes the main source of danger instead of one source among many. That’s why “no API keys” should be read as the beginning of the hard part, not the end of it.