Is that really a concern though in the same way API keys are? Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan? API keys are truly passwords, while refresh tokens are exchanged for a password.

Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.

The accepted norm is, increasingly, full disk access, regardless of how bad of an idea it is. At a minimum, agents typically will have a way of obtaining new access tokens.

Refresh tokens don't solve anything in this case; they just shuffle the problem around, and introduce other complications of their own.

What you want are capability scoped credentials that are enforced on the backend. That is agnostic to credential issuance mechanism, although passkeys are the best.

Using these credentials effectively still presupposes hygiene that might not exist in a typical developer environment, eg no root credentials (or access to such) sitting anywhere. There's probably a good product and market for whoever can solve this in a low-friction way.

> Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan?

If you can store your refresh token outside of where LLMs regularly scan, then why not just store your API token in that place?

The point is that refresh tokens do nothing to increase security. If a refresh token can be used to get a token, then the refresh token might as well be the actual token.

It's akin to performing client-side password hashing. It doesn't make your password more secure, it just means your hash is now your password. If someone is able to sniff your traffic, hashing the password first doesn't change anything.

I grow so tired of half-baked security theater.