The title can be read to the melody of My Favorite Things. They are not though, do not be deceived.
Getting API tokens is tedious, they are getting easier to find but it still often feels buried in settings. Where to keep them? How to keep track of which key is for which thing? Should they be shared? How to easily remember which random long alphanumeric string is the one that I need?
The page for making them always has two types of tokens: one for managing account, one for service accounts or client tokens or whatever name they use there. Then they have different sets of overlapping similarly-named-but-slightly-different permissions, so sometimes you only realise halfway through that you are setting up the wrong kind.
It is understandable that there is two types - I don’t want some random app to have full API access to manage and delete accounts if I am admin, but it seems needlessly confusing a lot of the time. Then in GCP and similar there is the extra step of “Enable API” then get a key for it; but maybe the overly confusing dense-but-whitespacey UIs is a rant for another time.
On permissions: enough but minimal is annoying. I want to be able to easily and safely grant privileges needed to do a task. Ideally I could just give a bot admin access and trust it not to do anything bad! But it will probably run up a huge bill by mistake and then delete or lock a bunch of accounts.
And on where/how to use them. LLMs seem to have gotten better at not just inlining API keys into HTML or app code. Alternatives other that env files still seem inconsistent, and “don’t read my env files” in AGENTS.md will not save you. Making it faster and easier to revoke/rotate keys and just expecting them to be exposed is probably a direction to go in. Just assume things will be compromised and hope they don’t run up huge costs while your token is public.
There are very smart people working on better ways to manage all this stuff. For know I will just continue to complain about it and see if I can vent out any good ideas for improvements.
