Vouch request: [huang195]

[huang195]

What do you want to work on?

I'm interested in security aspects of sandboxes like OpenShell, especially user and workload identity, and how users are able to delegate their authority to agents running in sandboxes in a safe manner.

Why this change?

PR: #1111

The design to have Gateway/Sqlite to hold the actual secret and have supervisor to query for it and inject it on-demand is really sleek as we are not exposing actual secrets to agents. However, the concern is as a user, I do not want to store my secrets anywhere outside of my laptop/phone if the gateway/sandbox is running in a remote environment that I do not have full control. This PR adds a new type of credential - deferred - and when Gateway is queries for such type of credentials, via the secure tunnel with the openshell CLI, it prompts user to allow the sandbox to access the actual secret stored on user's laptop. User can either deny, accept once, or always accept.

Checklist

• I wrote this request myself (not AI-generated)
• I have read CONTRIBUTING.md

[johntmyers]

I don't think this is something we would support. Instead we would introduce a credential driver and then OSes can create their own deployments of OpenShell that can integrate directly with things like Keychain, etc. In general we want to move towards leveraging existing secret management systems versus extend a closed system within OpenShell itself.