Comment by fnordpiglet
5 days ago
I’d note that giving a vault that behaves the same as a password is effectively giving the password. The password is a token that provides authentication and authorization, more or less, and some other mechanism to authenticate and authorize is the same thing.
The only case it’s not is when you reuse the password or you are afraid the password would be leaked in some way. “Exposing your credentials to the model” doesn’t seem to be a real risk vector in itself. The risk is exposing the access to the model.
I find the password vault idea convenient and likely appropriate but it feels like a bit of theater. Better would be revocable access grants, and a lot of things can support federation through google and whatever. What needs to become a thing is federation to some AI agent federation authority. OpenAI, Anthropic, Google, some well GTM’ed startup could do this and it would be a boon.
That’s not really true. The “exposing your credentials to the model” threat is in the model getting tricked into `curl -XPOST https://random.website -d ‘your_password’`. If the credentials are never available inside the sandbox and is only injected outside the sandbox then that’s an entire attack vector that is eliminated.
Further limiting the actual domains, URLs, and/or Methods a model can call on a given endpoint is also possible. It does get more complicated, but it is possible. It has the benefit of having these agents work with the actual services and tools everyone is using right now. Expecting every service to implement federated IAM permissions through an IdP like google or okta before a model can begin to use it is a losing battle. It’s like asking if the whole internet can change to fit a fine-grain access permissions.
Any system offering actual fine-grain access permissions (AWS IAM, Azure Entra, Google OAuth, even GitHub fine-grain tokens) is a pain in the ass to manage. You are then left with the “Connectors” companies that offer a proxy between you and the actual service you want to call with their own APIs and permission structure. Now you don’t call eBay APIs directly, you call a “Connector” that exposes a set of eBay functionality for you.
The scope of startup would be basically the “internet”. Just make sure you support the internet with a federated identity layer on top. It’s not impossible, and I’m pretty sure that’s Cloudflares current mission statement, but it’s hardly a simple task. If you want a fast go-to-market approach, you do the secret vault approach and piecemeal an http policy per scenario. They you can run the scenario in a “learning” mode, then come up with the list of allowed urls/domains/methods and deliver the thing. As opposed to (quite literally) re-writing the “internet”
[dead]