I think this is another oppertunity for folks to think of security, especially technical folks. (And maybe even another market pricing differentiator): User account management systems should more widely allow users to make permission-restricted 'subaccounts'. In this bold new era where folks are delegating their machines to take actions on their behalf, we need a new way that is far more fine grained than "all, ask every time, or nothing".

Choosing how to sub-divide abilities, and allowing the user to manage that, will be an art unto itself, and depend largely on the system. Thinking a banking API with a rule like "Allow sub user to send payment to water utility once per month, not to exceed $200". The user only needs to intervene if something goes wrong and the amount goes over.

Which is in turn why for convenience, security is a bad thing, making people who do not think about threat models in their sleep opt out.

Problem is striking the right balance, and auto-forwarding your agent to foreign machines is not the right balance. At least not without being able to filter and approve individual signing requests.

It's an inherent tension, and is also why so many things are insecure. People hate friction, and so they don't use secure stuff and turn security features off. Security abominations like "curl | bash" and package managers that traverse trees and download stuff and run scripts are popular for a reason.

It's true in the real world too which is why even in secure buildings a person can often slip in by coat-tailing someone. Stopping every single person to check ID is cumbersome and slows everyone down. People have stuff to do.

Truly high security environments are zero-tolerance, which makes them annoying and expensive to work in. I've talked to people who have worked in US military and CIA/NSA places and a very meaningful amount of time is spent complying with security and jumping through hoops. Even with all that, stuff gets leaked and stolen.

> In security, friction is a GOOD thing.

Oh boy, it isn't. Friction leads to frustration and therefore more likelihood to ignore the importance altogether.

you can make your SSH agent do that, no need to use bitwarden.

If you're using say yubikey for hardware ssh key (via gpg ssh agent/smartcard interface) you can also make it require physical touch of the key to confirm every operation

1Password too, FWIW

Or in a Yubikey and set the touch-required mechanism (light in the key will blink when it needs a touch to continue the auth).

1Password also supports this BUT that does not prevent your agent from being forwarded and you still have to inspect each command being used if you don't trust your agent.

Halfway better would be a separate key for each concern, then check that the key you expect to be used is being used before authorizing.

I've been using secretive on the mac for exactly this.

[flagged]

> keystone of secure infrastructure

But only when YOU choose where your SSH agent is accessible.

I find a lot of people take a very backward approach to agents: They adopt desktop versions with full access first, and only later discover sandboxes and cloud environments.

Claude and ChatGPT both come with free cloud sandboxes that work great! If they are just writing code there's little reason to hand over your laptop.

At work we have rather strict rules for how to run AI agents, and for good reasons apparently. The problem is that once these rules are in place and enforced, using an agent is just more hassle that I feel it's worth. The agents work in complete isolation in a VM with access to pretty much nothing. Some colleagues are making good use of them, but just looking at the policies and tooling we have put in place makes me give up in advance.