feat(policy): extend provider attachment proposals

[cheese-head]

Summary

Extends support for provider attachment requests in the draft policy proposal workflow. In-sandbox agents can now inspect attached providers through policy.local, submit a requestProvider proposal
for an existing host-managed provider, and let an operator approve that attachment through the same draft review path used for network policy changes.

Changes

• Extended draft policy chunks with proposal context fields for human summaries, intent summaries, request type, provider name, and provider type.
• Added gateway-side validation and approval handling for provider draft chunks.
• On provider proposal approval, attaches the requested existing provider to the sandbox spec, validates provider type when supplied, dedupes provider names, and preserves provider limit
  enforcement.
• Added sandbox access to ListSandboxProviders so policy.local can show attached provider metadata without exposing secrets.
• Added GET /v1/providers and requestProvider support to the sandbox-local policy API.
• Updated proposal status checks so approved provider requests report as locally applied once attachment and effective policy coverage are visible.
• Updated the TUI draft inbox to display human summaries, provider proposal details, validation results, rejection guidance, and L4-only scope warnings.
• Made provider profile network policy composition default-on via providers_v2_enabled, while keeping an explicit opt-out.
• Expanded GitHub and GitLab provider profile binaries to include curl and node.
• Updated provider docs and the in-sandbox policy advisor skill with the new provider request flow.

Checklist

• I have run mise run pre-commit
• I have run relevant tests
• I updated docs for user-facing behavior
• I verified no secrets or credentials are included

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[johntmyers]

This is interesting but I would find it likely that by requesting a provider, the workload is also requesting access to credentials needed to use that provider. When a provider is attached to an already running sandbox, the env placeholders cannot be updated in the current running userland process. I also would worry that attaching a provider may bring in too many allowances that aren't fully needed vs the policy advisor requesting the minimal needed access.

Is there a specific use case around this?

[cheese-head]

That's a good point although provider access is still useful because the credential values are represented as placeholders. The running agent does not need the raw secret, and in some flows it does not need its own process env mutated either: after approval, it can inspect the attached provider metadata, see the credential key, and use the corresponding placeholder in requests that pass through the sandbox proxy.

For example, suppose an agent needs to comment on a GitHub PR. A narrow network rule can allow POST /repos/NVIDIA/OpenShell/issues/123/comments, but it does not provide a GitHub token. A provider proposal lets the agent ask the operator to attach the existing github provider.

After approval, the agent can inspect attached providers, see that GITHUB_TOKEN is available, and use the placeholder directly

sequenceDiagram
      participant Agent as Running agent
      participant PolicyLocal as policy.local
      participant Gateway as Gateway
      participant Proxy as Sandbox proxy
      participant GitHub as api.github.com

      Agent->>PolicyLocal: POST /v1/proposals requestProvider(github)
      PolicyLocal->>Gateway: Submit provider proposal
      Gateway-->>PolicyLocal: Pending draft chunk

      Note over Gateway: Operator approves provider attachment

      Agent->>PolicyLocal: GET /v1/providers
      PolicyLocal->>Gateway: ListSandboxProviders
      Gateway-->>PolicyLocal: github exposes GITHUB_TOKEN
      PolicyLocal-->>Agent: credential key: GITHUB_TOKEN

      Agent->>Proxy: POST /repos/.../comments<br/>Authorization: Bearer openshell:resolve:env:GITHUB_TOKEN
      Proxy->>Proxy: Resolve placeholder from refreshed provider credentials
      Proxy->>GitHub: POST /repos/.../comments<br/>Authorization: Bearer real token
      GitHub-->>Proxy: 201 Created
      Proxy-->>Agent: Response

Loading