Sallyport and Auth0 Token Vault
A vault that hands the token to your code, which is the pattern the MCP specification refuses.
Token Vault stores a user’s third-party tokens and gives your application a clean way to get one when it needs it. For a normal web backend that is a good design and Auth0 builds it well.
| Them | Sallyport | |
|---|---|---|
| Where the token ends up | In your agent’s process | On the wire from our executor, and nowhere else |
| Per-call human approval | No | Yes |
| Who makes the upstream call | Your code | The gateway |
| MCP 2026-07-28 posture | The client receives the token | The server holds it, as the revision requires |
Where they are ahead
Identity infrastructure, breadth of connections and an ecosystem you can hire for. If your agent is a feature inside an application you already secure with Auth0, staying there is reasonable.
Where the difference is
An agent is a program that decides what to do with what it holds. A token in its process is a token in its context, its logs and its retries. The MCP revision of 2026-07-28 says a server holding tokens bound to a user must not transmit them to the client. We execute the call so the question never comes up.