Credentials are not property. An API key, an access token, a service account — each is a permission on someone else's infrastructure, revocable at will, and in most cases the provider's terms forbid transferring it. This is about the security dimension of that: what you are exposed to, and how to limit it.
For AI-provider credentials specifically, see the companion guide on buying AI API access; this one covers cloud accounts, service accounts, and credential handling generally.
The Exposure Nobody Prices In
A credential you buy may be attached to activity you did not create. If a cloud account was used for abuse before you acquired it, the suspension lands on you. If it was funded with a fraudulent card, the chargeback cascade takes the account and everything running on it.
Shared credentials mean shared blast radius. If the same key is sold to several buyers, one of them triggering a rate limit or an abuse flag kills access for all of them. You have no way to know how many copies exist.
Your own systems inherit the risk. Wiring a purchased credential into your production application means your uptime now depends on a stranger's account standing.
That last point is the one that turns a $50 purchase into a real incident.
What Gets Sold Here
Cloud service accounts — AWS, GCP, Azure accounts with credits. Credits are usually non-transferable promotional grants; accounts sold with them are frequently created fraudulently at scale.
Service-account keys — machine credentials for a specific project. Narrower scope, but still someone else's project.
Pre-paid balances on any provider.
Endpoints the seller genuinely operates — this is a service, and it is the legitimate end of the category.
Handling Credentials Safely
If you do buy, treat the credential as untrusted from the moment you receive it.
Never paste it into production first. Test in an isolated project with no access to your data.
Check the permission scope immediately. An over-scoped credential — one that can read storage, create resources, or modify billing — is a liability even if the seller is honest. Ask for the narrowest scope that does what you need.
Set a hard spending cap where the provider allows it, before the first real call.
Check for IP allowlists and rate limits that would break your use case.
Rotate anything you can rotate. If the provider permits regenerating the key under the same account, do it — it invalidates any copies the seller kept.
Never send your own existing keys to anyone. "Send me your key so I can test it" is credential theft with a polite framing, and there is no legitimate version of that request.
Red Flags
Prices below the provider's own cost. A raw credential posted anywhere public — providers scan for these and revoke automatically. Refusal to demonstrate a live call. No detail on quota or rate limits. Vagueness about whose account it is. Any request for your credentials in return.
Verifying Under Escrow
On Escrozon funds are held in escrow while you check the delivery:
- Have the seller demonstrate the credential working, live.
- Test it yourself from an isolated environment, several times over several hours — not one call.
- Verify the remaining quota through the provider's own usage endpoint, not a screenshot.
- Check the permission scope and set a spending limit.
- Test at realistic volume; rate limits only appear under load.
- Confirm receipt only when all of that holds.
If access dies afterwards, your recourse is against the seller through a dispute, and only the deal chat record of what was promised will support it.
The Safer Alternatives
Provision your own account. Slower, and it is the only version where you are the provider's customer with actual rights.
Buy a service, not a credential. An endpoint the seller operates as a business is a real transaction with a real counterparty.
Buy software you run. Model weights and serving code cost more up front and cannot be revoked by anyone.
Frequently Asked Questions
Is buying cloud credits ever legitimate? Promotional credits are almost always non-transferable and tied to the account they were granted to. Accounts sold with credits are frequently created in bulk fraudulently. Treat the whole category as high risk.
The credential works. Am I safe? It works now. That says nothing about the account's standing, how many copies exist, or what it was used for before you.
Can I limit the damage if it is revoked mid-operation? Design for it: never make a purchased credential a single point of failure, keep a fallback path, and monitor for auth errors rather than discovering them through customer complaints.
What about credentials for a service the seller built? Much safer, because you are buying access to something they operate. Ask about uptime commitments and what happens if they stop running it.
Should I ever share my own API key? No. There is no legitimate reason for a counterparty to need it.
