Feature: Better secret management for agents
Problem
Many agent repositories store secrets insecurely (e.g., plaintext .env files). This makes secrets easy to leak via commits, logs, malicious dependencies, or other processes. Safeclaw should provide safer, opinionated defaults and tooling to reduce this risk.
Proposed Direction
Introduce a unified secret management layer in safeclaw that replaces direct .env usage and reduces plaintext exposure. Safe and opinionated defaults for security is preferred.
Key ideas:
- Provide a
safeclaw secrets interface (CLI + skill API) so agents retrieve secrets via safeclaw instead of reading .env directly.
- Support secure backends such as OS keychain, encrypted local files, or CI-provided secrets (pluggable provider model).
- Add tooling to detect insecure secret practices (e.g.,
.env, hardcoded tokens) and guide developers toward safer alternatives.
- Allow safeclaw to inject secrets into subprocesses in a scoped way (instead of exporting globally), and redact them from logs.
- When running in a VM sandbox, ensure secrets are brokered by safeclaw and not persisted to repo or disk unnecessarily.
This does not need to be a fully-fledged secret manager initially. The goal is to provide safer defaults, reduce common leaks, and create a clear abstraction that can evolve over time.
Acceptance Criteria (Initial Scope)
- Provide a minimal
safeclaw secrets get <name> interface with at least one secure backend (keychain, encrypted file, or env passthrough).
- Add a scan or warning for
.env usage and other obvious insecure patterns.
- Allow safeclaw to run commands with scoped secret injection instead of requiring global environment variables.
- Ensure secrets retrieved via safeclaw are not printed in logs by default.
Implementation Notes
Suggested starting points (flexible):
- Define a provider interface for secret backends.
- Implement one simple secure backend first (e.g., OS keychain or encrypted file).
- Add detection/linting for unsafe patterns like
.env.
- Integrate with safeclaw run / sidecar / VM execution paths.
Feature: Better secret management for agents
Problem
Many agent repositories store secrets insecurely (e.g., plaintext
.envfiles). This makes secrets easy to leak via commits, logs, malicious dependencies, or other processes. Safeclaw should provide safer, opinionated defaults and tooling to reduce this risk.Proposed Direction
Introduce a unified secret management layer in safeclaw that replaces direct
.envusage and reduces plaintext exposure. Safe and opinionated defaults for security is preferred.Key ideas:
safeclaw secretsinterface (CLI + skill API) so agents retrieve secrets via safeclaw instead of reading.envdirectly..env, hardcoded tokens) and guide developers toward safer alternatives.This does not need to be a fully-fledged secret manager initially. The goal is to provide safer defaults, reduce common leaks, and create a clear abstraction that can evolve over time.
Acceptance Criteria (Initial Scope)
safeclaw secrets get <name>interface with at least one secure backend (keychain, encrypted file, or env passthrough)..envusage and other obvious insecure patterns.Implementation Notes
Suggested starting points (flexible):
.env.