Is it safe to give an app your admin key?
Last verified
The honest answer: it depends entirely on where the key ends up. An admin key on a server you don't control is a standing risk. The same key in your device's secure storage, never transmitted, is a much smaller one.
Here is what to actually ask.
What an admin key can do if stolen
Be clear about the blast radius before evaluating any tool:
- Read everything financial — organisation spend, per-project cost, per-model usage
- Enumerate structure — projects, members, keys
- Delete every API key in the organisation — which takes down every service you run
What it cannot do is make inference calls. So the direct risk is not "they run up my bill"; it is disclosure and destruction. That distinction matters when you're weighing it against alternatives.
The six questions
1. Where is the key stored?
The only question that really matters.
- Best: on your device only, in OS-backed secure storage (iOS Keychain, macOS Keychain, Windows Credential Manager), never transmitted.
- Acceptable: on a server, encrypted at rest with a key you control, with a stated key management model.
- Bad: on a server, unstated. If a tool won't tell you, assume the worst.
2. Does it ever leave the device?
"We never see your keys" and "we encrypt your keys" are different claims. The first means their servers cannot be compromised into leaking your key, because it was never there. The second means it depends on their operational security forever.
Ask which one they mean.
3. Does it need write access, or just read?
Reading spend needs read access. Revoking keys needs write. A tool that only shows dashboards should not need the ability to delete your keys.
If a tool takes an admin key with full scope for a read-only feature, that's a design smell.
4. Can you scope it down?
One admin key per consumer, named for that consumer, so you can revoke one integration without disrupting the others. If a tool encourages you to reuse the key you already have everywhere, it is making your incident response worse.
5. What happens if the vendor is breached?
Work it through. If their database leaks tomorrow, is your key in it? If the answer is yes, you are trusting their security posture permanently, on top of your own.
6. Can you verify any of this?
Open-source code, a published security model, or observable behaviour (check whether the app makes a network call when you paste the key). Claims you can check are worth more than claims you can't.
The alternatives, honestly
Don't connect anything. Use the provider dashboards. Free, safe, and nobody does it daily — which is precisely why spend surprises happen.
Use a proxy instead. Helicone, Portkey and similar route your traffic and derive cost from observed requests. No admin key needed. But the tradeoff is real and arguably larger: a proxy sits _in your request path_, so it can see prompts and responses, add latency, and take your application down if it has an outage. See proxy-based vs billing-API cost tracking.
Read local data. For locally-run coding agents, session logs on disk carry full token counts. No credential of any kind. This only works for tools that write local logs, but where it works it is strictly the safest option.
Where TKN sits
Since this page is on TKN's site, the disclosure is owed:
TKN needs an admin key to read your billing data. It stores it in the iOS Keychain — Secure Enclave-backed, device-only, excluded from iCloud backup — behind Face ID, and does not upload it. TKN's servers do not hold your provider keys, so a breach of TKN does not expose them.
The tradeoff you accept is different: the key is on a phone, so losing the phone matters. That's what the biometric lock is for, and the honest framing is that you are trading server-side risk for device-side risk, not eliminating risk.
TKN is also open source, so this is checkable rather than merely asserted.
The short version
Give an admin key to a tool that keeps it on your device, needs the access it asks for, and lets you verify the claim. Be reluctant with anything that holds it server-side and won't explain how.