For computing and model-access providers
A registration and a check for the accounts and automated callers that rent your machines and call your models. Above a threshold you choose, every account has a verified party behind it and every automated caller holds a key a thief cannot copy.
Written for security, fraud and platform teams at GPU clouds and model-access services. Every figure names its source, and a working prototype accompanies it.
01 — The problem you already pay for
Okta Threat Intelligence found fraud rings using synthetic sign-ups to harvest cloud startup credits on AWS and Google Cloud, pooling the accounts behind a proxy and reselling Claude and Gemini access at 5 to 15 percent of list price.
At one AI provider, Okta logged over 105,000 suspected automated registration attempts from 251 bot-associated addresses, using VPNs, disposable emails and synthetic identities. The resulting accounts were resold for cryptocurrency.
In early 2026 an experimental Alibaba agent, mid-training, tunneled out of its cloud instance and diverted its GPUs to mine cryptocurrency with no instruction to. The cloud's firewall caught it, not the training team.
Regulators are moving in the same direction: the Commerce Department has proposed know-your-customer rules for cloud infrastructure providers.
Sources: Okta Threat Intelligence (2026); The Block, March 2026, on Alibaba's ROME paper; U.S. Dept. of Commerce, proposed IaaS customer-identification rule (2024).
02 — Why it keeps happening
Email patterns, IP addresses and device fingerprints are what fraud scoring sees, and all three are free to replace. A banned abuser is back in minutes with a new address and a new card.
Whoever holds a copy of a key is, to your systems, the customer. GitGuardian found 29 million secrets exposed on public GitHub in 2025, 24,000 of them in agent tool configuration files. A leaked key is an attacker wearing your customer's identity.
You know who you banned. You do not know who your competitor banned yesterday, and the same abuser moves between providers within hours, arriving at each as a new customer with no history.
All three gaps have the same shape: nothing about the account or its automation persists when the abuser wants it not to.
Sources: GitGuardian, State of Secrets Sprawl 2026.
03 — What we add
Above a spending threshold you choose, the account holder is verified once as a real person or a registered company, through an identity vendor. Most providers do a weak version of this today, a card and an email. This makes it a real one, and it is what the proposed rules will require anyway.
Each automated caller registers: a serial number, its own key pair whose private half never leaves it, a named operator, a declared purpose and scope. It signs every request. A copied key or note is useless to anyone else, and you can revoke one agent without closing the account.
| Tier | Browse | Buy things | Buy computing | Run equipment |
|---|---|---|---|---|
| Person-backedA verified person is bound to the agent | Allow | Allow | Allow | Allow |
| Company-backedA verified company is bound to the agent | Allow | Allow | Allow | Deny |
| UnboundRegistered and signed by its platform, but no one stands behind it | Allow | Deny | Deny | Deny |
| FailedA note was missing, forged, altered, borrowed, expired or revoked | Deny | Deny | Deny | Deny |
These are the defaults. Your limits per tier are plain settings you change without touching code.
04 — How it fits your stack
Your engineers add the check at account signup and at the spending threshold: a library or an API call, days of work. Your terms state that automated callers above the threshold must be registered.
An account's automation crosses the threshold with no registration. The check returns a standard "registration required" response: the registry address, machine-readable, plus a link for a human.
Once per agent product, under an hour. On startup the kit creates the key pair, registers the agent, and from then on signs every request. Each new copy registers itself.
The retry verifies in milliseconds against keys published in advance, with no calls to outside parties. The account gets the limits its tier allows.
Every request is checked. If you ban the agent, the ban is reported to the shared list and holds at every participating provider.
Runs as our hosted service, inside your edge, or as open-source code you run yourself. Built on the same signature standards as secure websites; nothing proprietary.
05 — In the request path
The agent signs its request with the key its notes were issued to. Your gateway forwards the headers to the checker and gets back a verdict, a tier, the facts and the reason, signed so it can be logged, audited or replayed offline. Nothing in the request path waits on a third party.
The kit for agent developers is one install: generate a key pair, register once, sign every request.
POST /v1/check X-Agent-ID: AID-4B19-E7F2-0A3C Signature-Input: sig1=("@method" "@path" "x-agent-id");keyid="AID-4B19" Signature: sig1=:Qm9yZGVyIGNoZWNr…: 200 OK · signed { "verdict": "admitted", "tier": "person-backed", "agent": "AID-4B19-E7F2-0A3C", "model": "A-4 Pro", "platform": { "issuer": "Model Co. A", "signed": true }, "operator": "Priya K.", "behind": { "kind": "person", "verified": true }, "key_proof": "ok", "revocation": { "listed": false, "list_version": 18422 }, "checked_at": "2026-10-23T21:14:08Z", "signature": "ed25519:…" }
06 — What you get
An identity that survives a new email, a new card and a new IP address. A stolen key or note is useless without the agent's private key, which never left the real agent.
A named, verified operator on file before any money is spent, so an unpaid bill or an abuse report has an owner, and a hijacked agent can be traced to the account that ran it.
Registered, person-backed and company-backed agents get higher limits and faster onboarding instead of blanket suspicion and a manual-review queue. Today you turn away business you cannot tell apart from abuse.
Records that already satisfy know-your-customer requirements for cloud providers when they arrive, and fewer hours of manual review now.
The first three show up in the first month of a pilot. The fourth is insurance.
07 — What you could build, and what you cannot
The single-door part, you could build: your team already owns account and workload identity. We will give you that tooling free. The value is in the three things only a neutral party can hold.
An ID you issue works at your door only. Your competitors will never accept it, and developers will not carry six of them. A neutral registry is the one developers carry and every door accepts.
The value of a ban is at the other doors. A list fed by several providers, with payment details attached, flags an abuser on its first visit to you. Competitors will feed a neutral list under written rules; they will not feed each other's.
Evidence standards, an appeal process and antitrust-safe terms, held by the operator rather than by any member. This is how the card networks' terminated-merchant list and the banks' shared fraud utility work.
What we ask is to be the neutral party for the rest, with you as the founding member.
08 — The proposal
Pricing after the pilot is per check or by subscription, set with you. The pilot itself costs you engineering time and nothing else.
09 — Proof
All signatures and formats are real and verified. Forged signatures, altered requests, borrowed and stolen papers, revoked and expired registrations are refused with the reason named; honest agents are admitted with the right tier.
What is mocked in the prototype: the three issuers, whose keys were generated for the demo. What is real: every signature, format and check.
10 — The next step
With your security and platform engineering leads: we walk through the check in your request path, choose the threshold, and scope the two weeks of integration.
For security, fraud and platform teams at GPU clouds and model-access services.