feat(cli): warn when --env values look like credentials

[r3v5]

Problem Statement

openshell sandbox create --env JIRA_API_TOKEN=<real-token> accepts credential values without any warning. The agent inside the sandbox can read these values directly. The secure alternative — using a provider profile — exists but the CLI gives no indication that a better option is available.

The insecure path (--env) is frictionless. The secure path (providers) requires knowing about providers v2, the profile schema, and the import/create/attach workflow. Developers and AI agents building workflows take the path of least resistance.

Proposed Design

When openshell sandbox create receives --env flags with keys that look like credentials, emit an informational warning:

$ openshell sandbox create --env JIRA_API_TOKEN=xyzabc123 ...

⚠ JIRA_API_TOKEN looks like a credential passed as a plain environment variable.
  The agent inside the sandbox can read this value directly.

  To hide this credential from the agent, use a provider instead:
    openshell provider create --name my-jira --type jira --credential JIRA_API_TOKEN
    openshell sandbox create --provider my-jira ...

  See: https://docs.nvidia.com/openshell/latest/sandboxes/providers-v2

Detection heuristic

Warn when an --env key matches any of:

• *_TOKEN, *_API_KEY, *_SECRET, *_PASSWORD, *_CREDENTIAL
• *_ACCESS_KEY, *_SECRET_KEY
• Known credential env var names from built-in profiles (e.g., GITHUB_TOKEN, NVIDIA_API_KEY, JIRA_API_TOKEN)

Behavior

• Warning is informational only — does not block sandbox creation
• Suppressible with --no-credential-warnings for legitimate use cases
• When a matching built-in profile exists, the warning suggests the specific provider create command
• When no profile matches, the warning links to the custom profile docs

Dependencies

• Better experience if feat(providers): ship built-in Jira and MLflow provider profiles #2547 lands first (built-in Jira/MLflow profiles to suggest in warnings)
• Better experience if feat(providers): enable providers v2 by default #2545 lands first (providers v2 default-on so the suggested path works without extra setup)

Motivation

In opendatahub-io/agent-ops#7, JIRA_API_TOKEN and MLFLOW_TRACKING_TOKEN were passed as raw env vars. Neither the developer nor the AI agent building the workflow received any signal that a secure alternative existed.

Prior Art

• GitHub push protection — warns when a push contains credential-like strings
• npm audit — security warnings at the moment of decision
• Kubernetes Pod Security Admission — warns on insecure pod configurations

Agent Investigation

• --env flag parsed in crates/openshell-cli/src/main.rs under sandbox create
• Built-in profile credential env var names available via builtin_profiles() in crates/openshell-providers/src/profiles.rs
• Warning should be emitted in CLI before the CreateSandbox RPC call

Checklist

• Searched for existing issues — no issue tracks credential warnings in CLI
• Design includes suppression flag for false positives

[matthewgrossman]

📋 triage-agent

Triage Assessment

Classification: feature-valid

Summary

A non-blocking credential warning is a pragmatic way to steer users away from exposing secrets directly to sandboxed agents.

Investigation

parse_env_pairs validates only environment-variable syntax and reserved OPENSHELL_ names, after which sandbox_create places the values directly into SandboxSpec.environment. Built-in profile credential declarations are available through builtin_profiles(). #2549 is complementary discoverability work, not a duplicate.

Recommendation

Keep the issue open. Detect by key name only, never inspect or print values, keep the warning suppressible, and test matching, false positives, suppression, and secret-free output.

[letv1nnn]

I'd like to take this one