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
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
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 createreceives--envflags with keys that look like credentials, emit an informational warning:Detection heuristic
Warn when an
--envkey matches any of:*_TOKEN,*_API_KEY,*_SECRET,*_PASSWORD,*_CREDENTIAL*_ACCESS_KEY,*_SECRET_KEYGITHUB_TOKEN,NVIDIA_API_KEY,JIRA_API_TOKEN)Behavior
--no-credential-warningsfor legitimate use casesprovider createcommandDependencies
Motivation
In opendatahub-io/agent-ops#7,
JIRA_API_TOKENandMLFLOW_TRACKING_TOKENwere 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
Agent Investigation
--envflag parsed incrates/openshell-cli/src/main.rsunder sandbox createbuiltin_profiles()incrates/openshell-providers/src/profiles.rsCreateSandboxRPC callChecklist