Comment by whattheheckheck

Can you please elaborate on the agent signing up for a service piece? I'm curious to understand the use case more (type of agent, what credit, etc.).

The current modal assumes that you have a trusted entity whose able to save credentials to Agent Vault; that entity is likely not the agent itself because that would mean that the agent would have access to credentials. The agent is then simply configured to proxy requests through AV which attaches credentials at this proxy layer. Here are two examples:

Example 1:

- You have a backend that saves an API Key to AV for a specific vault and defines the service rules for how that credential can be used.

- That same backend mints a session-scoped token to AV and invokes the creation of a pre-configured sandbox, passing that token into it.

- The agent in the sandbox does what it needs to do, requests fully proxied through AV.

Example 2:

- A human operator manually goes into AV and adds an API Key.

- The human operator spins up an agent (could be an OpenClaw, Claude Code, etc.) in a pre-configured environment to route requests through AV. This can be done using non-cooperative sandbox mode with the AV CLI or through more manual configuration.

- The agent does what it needs to do, requests fully proxied through AV.

We're still working on smoothening it out but perhaps this gives you a better idea of how this might work.

AV does have a permission system that supports agents being able to save credentials to it and then subsequently using the proxy (maybe this is what you're targeting) but this isn't the use case that I've personally explored at much; definitely worth looking into tho.