A service account sounds like one step forward, two steps back.

It can limit the scope of accessible vaults, which can help but only if you do the legwork of keeping multiple copies of secrets in separate vaults and managing service account tokens.

But the token is just in an environment variable, which if we’re worried about this supply chain malicious library scenario, is no different than keeping your secrets in a plain text .env file.

And worse, a service account doesn’t prompt the user.

The functionality of `op run —env-file .env — some_app` which then prompts the developer is what we’d want in a dev environment, just with finer grained permissions and options to prompt every time.

But realistically, if someone can execute code on your computer, they can get to your entire 1Password account through scraping the app, key logging, sending keystrokes and screenshotting, etc.