Skip to main content

​
Short Answer

A key’s maximum spending power is your account balance — meaning that if any single key leaks, your worst-case loss is everything left in your account. Securing your keys comes down to four things: issue separate keys per purpose, give each key a permission boundary, cap how much any single key can spend, and keep keys out of anywhere someone else could see them.
The most commonly overlooked item: leaving “Unlimited Quota” enabled on a key exposes your entire account balance through that one key. Test keys in particular should always have a spending cap.

​
1. Give the Token a Permission Boundary

When creating a token, tick “Enable Advanced Options” to reveal the IP whitelist and available-models settings. Advanced token options: available models and IP whitelist This is the strongest protection available. Once set, only requests from the specified IPs can use the token — even if the key leaks, it is useless from any other machine.
Production servers usually have a fixed IP, which makes them an excellent fit for IP whitelisting. Enter your server’s public egress IP, not its internal address.
Do not enable this on dynamic-IP connections. Home broadband and office networks rotate their egress IP, and every call will fail the moment it changes. Use a spending cap instead for those environments.

​
Available-Models Whitelist (For Dedicated Tokens)

Leaving “Available Models” empty means no restriction — the token can call any model on the platform. Once you fill it in, the token can only use the models you listed. This cuts both ways:

Good fit

Single-purpose tokens: a service that only generates images, a token shared with an outside collaborator, or per-model budget isolation.

Poor fit

Everyday personal use and exploratory testing. You have to return to the console every time you switch models, and mismatched model aliases can break calls.
In most cases we do not recommend setting available models. See Do I Need to Set Available Models on a Token? for the full trade-off analysis.

​
2. Set a Spending Cap on the Token

This one applies to everyone, and doubly so for test keys. When creating the token, switch off “Unlimited Quota” and enter an amount under “Authorized Quota” — or use one of the presets below the field ($5 / $20 / $50 / $100 / $200 / $500). Token quota settings: disable unlimited quota and set an amount The point of a quota is to cap your loss at a number you can absorb:
  • A leaked key with a $20 quota costs you at most $20
  • A leaked key with “Unlimited Quota” on can cost you your entire account balance
A token’s maximum spending power is limited by your account balance. Setting a $500 quota does not reserve or freeze that money — it is purely a ceiling on that token’s consumption. What it can actually spend still depends on the balance available.

​
3. Keep Production and Test Keys Separate

Never use one key for both live traffic and local testing. Once they are separate, you can disable a misbehaving test token outright without touching production.
Give tokens recognizable names in the console (e.g. prod-image-service, test-model-compare-0729) rather than the default. It makes locating and disabling the right one much faster when something goes wrong. See Tokens and Groups.

​
4. Keep Keys Out of These Places

​
Code Repositories

This is the most common leak path by far. Once a key is committed to Git, it stays in the commit history even after you delete the file, and anyone with repository access can dig it out. Read from environment variables instead:
Add .env to .gitignore, and scan before you commit. This command works as a self-check:
The (^|[^A-Za-z0-9]) prefix in that pattern matters. Without it, the sk- inside ordinary words like task-, risk-, and disk- produces a flood of false positives that buries the real findings.

​
Public Docs, Screenshots, and Logs

Before publishing documentation or a technical write-up, review the prose, the code samples, and the screenshots. Console screenshots, terminal recordings, and error logs all routinely carry a full key. Use a placeholder such as sk-your-api-key in every example.
Public GitHub repositories are especially dangerous. They are continuously scanned by automated bots, and a leaked key is often exploited within minutes. Before open-sourcing a project, verify that neither the code nor the commit history contains a real key.

​
Conversations with AI and AI Agents

This risk path is only a couple of years old, and it is the one most often underestimated. Pasting a key into a chat box feels temporary, but in practice:

Transcripts hit the disk

AI coding tools typically store the full conversation as plaintext files on your machine, retained indefinitely and never cleaned up automatically.

Resuming re-transmits

Resuming an old session sends the entire transcript again as context, so the key is not sitting still.

File snapshots duplicate it

These tools often snapshot files before and after edits, so a script containing a key ends up copied several times over.

Any local process can read them

Those files are readable by any program running as you — a weaker boundary than your code repository has.
Always use a disposable key for AI tools and agents: create it separately, give it a small quota (say $5) and a short expiry, then delete it in the console the moment the task is done. Never hand a production key to an AI tool.

​
What to Do If a Key Has Already Leaked

1

Delete or disable the token immediately

Go to the token page and delete or disable the affected token. This is the only action that stops the bleeding right away, and it comes before any investigation.
2

Create a replacement token

Issue a new token — this time with a spending cap and whatever permission boundaries apply — and update your application config.
3

Check the logs for impact

Review your call logs for anomalies during the exposure window: unfamiliar models, unusual volume, or requests at hours you were not working.
4

Clean up the source of the leak

Track down where the key actually leaked — code, docs, screenshots, chat transcripts — and clean each one out. Otherwise the replacement key leaks the same way.

​
Common Questions

Most likely the wrong IP. You need the server’s public egress IP, not an internal address like 192.168.x.x.If you are calling from home broadband or an office network, the egress IP rotates with your ISP, and such environments are a poor fit for IP whitelisting — use a spending cap instead.To troubleshoot, clear the IP whitelist first, confirm calls recover, then add the correct IPs back one at a time.
No. An authorized quota is only a spending ceiling for that token, not a prepayment or a hold.You can give five tokens a $100 quota each while holding only $50 in the account — they share that $50, and once it runs out none of them work. A token’s maximum spending power is always bounded by the account balance.
There is no limit; create as many as you need.We suggest splitting them along project plus environment lines, e.g. prod-support-bot, prod-image-service, test-model-eval. Finer-grained tokens let you disable exactly one without disrupting anything else, and each token’s spending and logs can be reviewed independently.
No. Calls are rejected once the quota is exhausted, but the token itself remains. Just edit the token and raise the authorized quota in the console to resume — no need to create a new one or update your config.That is part of why a spending cap is worth setting: it is a recoverable brake, not a one-way destruction.
Check the call logs. Three signals matter most: models you never use, calls outside your working hours, and request volume that does not match your workload.See How Do I Investigate Unexpected Key Usage? for the full procedure.

Tokens and Groups

Full reference on creating, editing, and grouping tokens.

Token Model Whitelist

Whether to set available models, and what to watch out for.

Investigate Key Usage

Use logs to pin down the real caller behind unexpected usage.

Platform Data Security

How APIYI encrypts traffic and protects your data on the platform side.
Security is never a small matter. Every setting above lives on the token management page — a few minutes of configuration blocks the large majority of the risk.