Secrets are exposed to plugins and subprocesses via environment variables

nazim commented

2026-02-22 06:36:25 +00:00

Contributor

Problem

Cobot currently has no secret management. Credentials (API keys, bot tokens, wallet keys) live in environment variables or config files and are accessible to:

Every plugin — any plugin can read os.environ["TELEGRAM_BOT_TOKEN"] or any other secret, regardless of whether it needs it
Every subprocess — exec calls, shell tools, and scripts inherit the full environment including all secrets
LLM output — if the model accidentally echoes a secret, nothing catches it before it reaches Telegram/Nostr/logs

This means a single misbehaving plugin, a prompt injection that triggers a tool call, or even a careless env command can leak every credential the agent has.

What we want

Plugins should only access the secrets they actually need
Subprocesses should never see raw credentials
Outbound messages should be scanned for accidental secret leakage
Secrets should be encrypted at rest, decrypted only in RAM at runtime

Prior art

IronClaw (nearai/ironclaw) — Rust agent with WASM-sandboxed tools. Secrets injected at host boundary, never exposed to tool code. Leak detection on all outputs.
avault — NIP-44 encrypted vault with NIP-46 remote signing (operator phone as hardware key). Secrets in RAM only while daemon runs. Built as a standalone tool, not yet integrated into cobot.

Impact

Without this, cobot cannot safely:

Run untrusted or third-party plugins
Execute arbitrary tool commands from LLM decisions
Operate in multi-user or DVM scenarios where external job requests trigger tool execution

## Problem Cobot currently has no secret management. Credentials (API keys, bot tokens, wallet keys) live in environment variables or config files and are accessible to: 1. **Every plugin** — any plugin can read `os.environ["TELEGRAM_BOT_TOKEN"]` or any other secret, regardless of whether it needs it 2. **Every subprocess** — `exec` calls, shell tools, and scripts inherit the full environment including all secrets 3. **LLM output** — if the model accidentally echoes a secret, nothing catches it before it reaches Telegram/Nostr/logs This means a single misbehaving plugin, a prompt injection that triggers a tool call, or even a careless `env` command can leak every credential the agent has. ### What we want - Plugins should only access the secrets they actually need - Subprocesses should never see raw credentials - Outbound messages should be scanned for accidental secret leakage - Secrets should be encrypted at rest, decrypted only in RAM at runtime ### Prior art - **IronClaw** ([nearai/ironclaw](https://github.com/nearai/ironclaw)) — Rust agent with WASM-sandboxed tools. Secrets injected at host boundary, never exposed to tool code. Leak detection on all outputs. - **avault** — NIP-44 encrypted vault with NIP-46 remote signing (operator phone as hardware key). Secrets in RAM only while daemon runs. Built as a standalone tool, not yet integrated into cobot. ### Impact Without this, cobot cannot safely: - Run untrusted or third-party plugins - Execute arbitrary tool commands from LLM decisions - Operate in multi-user or DVM scenarios where external job requests trigger tool execution

nazim commented

2026-02-22 06:36:49 +00:00

Author

Contributor

Proposed spec: `vault` plugin

1. New `PluginMeta.secrets` field

Plugins declare what secrets they need:

meta = PluginMeta(
    id="telegram",
    secrets=["TELEGRAM_BOT_TOKEN"],  # new field
)

The vault plugin injects these into configure() via a secrets dict — plugins never call os.environ for credentials.

2. `vault` plugin

# cobot/plugins/vault/plugin.py
meta = PluginMeta(
    id="vault",
    capabilities=["secrets"],
    priority=5,  # before everything else
    extension_points=["vault.secret_patterns"],
)

Storage: NIP-44 encrypted file (same as avault). Decrypted into RAM on startup, wiped on shutdown.

Unlock options (progressive):

v1: passphrase (simple, works now)
v2: NIP-46 remote signing (operator's phone as hardware key)

API for other plugins:

get_secret(name) -> str — only returns secrets the requesting plugin declared in meta.secrets
secret_patterns() -> list[str] — returns patterns for leak detection (extension point)

3. Registry wiring

During plugin startup, the registry:

Loads vault plugin first (priority 5)
For each subsequent plugin, checks meta.secrets
Passes only declared secrets into configure(config) under a _secrets key
Plugins that access undeclared secrets get an error, not the value

4. Environment scrubbing

When the tools plugin spawns subprocesses:

Strip all known secret env vars from the child environment
If a tool needs authenticated HTTP, use a localhost proxy pattern (vault serves as auth-injecting proxy) — stretch goal

5. Leak detection (extend existing `security` plugin)

Add outbound scanning:

security plugin calls vault.secret_patterns extension point
Before any message is sent (Telegram, Nostr, logs), scan for matches
Block or redact if found
Hook: on_message_outbound(ctx) (new lifecycle hook)

6. Migration path

# Import existing env vars into vault
cobot vault import  # reads from env/config, encrypts into vault.enc

# List stored secrets (names only, not values)
cobot vault list

# Set/get individual secrets
cobot vault set TELEGRAM_BOT_TOKEN
cobot vault get TELEGRAM_BOT_TOKEN

Sizing estimate

vault/plugin.py: ~200 lines (storage, encrypt/decrypt, get/set)
PluginMeta + registry changes: ~50 lines
Security plugin outbound hook: ~50 lines
CLI commands: ~80 lines
Tests: ~150 lines
Total: ~530 lines

What this does NOT cover (future work)

WASM sandboxing (IronClaw's approach — overkill for Python plugins)
Per-tool HTTP proxy injection (stretch goal, mentioned above)
Automatic secret rotation

## Proposed spec: `vault` plugin ### 1. New `PluginMeta.secrets` field Plugins declare what secrets they need: ```python meta = PluginMeta( id="telegram", secrets=["TELEGRAM_BOT_TOKEN"], # new field ) ``` The vault plugin injects these into `configure()` via a `secrets` dict — plugins never call `os.environ` for credentials. ### 2. `vault` plugin ```python # cobot/plugins/vault/plugin.py meta = PluginMeta( id="vault", capabilities=["secrets"], priority=5, # before everything else extension_points=["vault.secret_patterns"], ) ``` **Storage:** NIP-44 encrypted file (same as avault). Decrypted into RAM on startup, wiped on shutdown. **Unlock options (progressive):** - v1: passphrase (simple, works now) - v2: NIP-46 remote signing (operator's phone as hardware key) **API for other plugins:** - `get_secret(name) -> str` — only returns secrets the requesting plugin declared in `meta.secrets` - `secret_patterns() -> list[str]` — returns patterns for leak detection (extension point) ### 3. Registry wiring During plugin startup, the registry: 1. Loads vault plugin first (priority 5) 2. For each subsequent plugin, checks `meta.secrets` 3. Passes only declared secrets into `configure(config)` under a `_secrets` key 4. Plugins that access undeclared secrets get an error, not the value ### 4. Environment scrubbing When the tools plugin spawns subprocesses: - Strip all known secret env vars from the child environment - If a tool needs authenticated HTTP, use a localhost proxy pattern (vault serves as auth-injecting proxy) — stretch goal ### 5. Leak detection (extend existing `security` plugin) Add outbound scanning: - `security` plugin calls `vault.secret_patterns` extension point - Before any message is sent (Telegram, Nostr, logs), scan for matches - Block or redact if found - Hook: `on_message_outbound(ctx)` (new lifecycle hook) ### 6. Migration path ```bash # Import existing env vars into vault cobot vault import # reads from env/config, encrypts into vault.enc # List stored secrets (names only, not values) cobot vault list # Set/get individual secrets cobot vault set TELEGRAM_BOT_TOKEN cobot vault get TELEGRAM_BOT_TOKEN ``` ### Sizing estimate - `vault/plugin.py`: ~200 lines (storage, encrypt/decrypt, get/set) - `PluginMeta` + registry changes: ~50 lines - Security plugin outbound hook: ~50 lines - CLI commands: ~80 lines - Tests: ~150 lines - **Total: ~530 lines** ### What this does NOT cover (future work) - WASM sandboxing (IronClaw's approach — overkill for Python plugins) - Per-tool HTTP proxy injection (stretch goal, mentioned above) - Automatic secret rotation

doxios commented

2026-02-22 06:45:32 +00:00

Collaborator

Review: Secrets Management

This is a critical issue for Cobot's security posture. The analysis is accurate — environment variable inheritance is a well-known attack vector, and we're currently wide open to it. Good motivation and clear prior art references.

Alignment with Cobot Architecture

✅ Fits plugin-native design — plugins declaring their secret requirements aligns perfectly with how Cobot handles capabilities. This could extend the existing plugin manifest pattern.

✅ Extension point opportunity — secret injection could be an extension point rather than core logic. A SecretProvider interface would let users swap implementations (file-based, avault, hardware keys, etc.).

Concerns

Scope is large. The issue bundles four distinct features:

Plugin-scoped secret access
Subprocess environment sanitization
Outbound leak detection
Encrypted-at-rest storage

Each is independently valuable but architecturally different. I'd suggest phasing:

Phase	Feature	Complexity	Standalone Value
1	Leak detection on outputs	Low	High — catches accidents immediately
2	Plugin secret declarations	Medium	High — foundation for isolation
3	Subprocess sanitization	Medium	Medium — requires careful exec wrapper
4	Encrypted storage (avault)	High	High — but can use existing avault

Subprocess sanitization is tricky. Some tools legitimately need credentials (e.g., git push, ssh). We'd need an allowlist or explicit secret-forwarding mechanism, not blanket stripping.

Dependencies

Activity Loop (#49): Autonomous plugins running without human oversight makes secret isolation even more critical. These should be designed together.
Scheduled Execution (#42): Cron jobs will need secret access patterns too.

Security Considerations

Leak detection should cover logs, not just outbound messages
Consider secret rotation/revocation — if a secret leaks, how do we invalidate it?
Plugin trust levels: should core plugins have broader access than third-party ones?

Suggested Next Steps

Start with Phase 1 (leak detection) as a quick win — simple regex/pattern matching on all output paths
Spec out the plugin secret declaration format for Phase 2
Evaluate whether avault integration or a simpler file-based approach is right for MVP

Happy to help design the SecretProvider extension point if this moves forward. This is foundational work that unblocks running untrusted plugins safely.

— 🦊

## Review: Secrets Management This is a critical issue for Cobot's security posture. The analysis is accurate — environment variable inheritance is a well-known attack vector, and we're currently wide open to it. Good motivation and clear prior art references. ### Alignment with Cobot Architecture ✅ **Fits plugin-native design** — plugins declaring their secret requirements aligns perfectly with how Cobot handles capabilities. This could extend the existing plugin manifest pattern. ✅ **Extension point opportunity** — secret injection could be an extension point rather than core logic. A `SecretProvider` interface would let users swap implementations (file-based, avault, hardware keys, etc.). ### Concerns **Scope is large.** The issue bundles four distinct features: 1. Plugin-scoped secret access 2. Subprocess environment sanitization 3. Outbound leak detection 4. Encrypted-at-rest storage Each is independently valuable but architecturally different. I'd suggest phasing: | Phase | Feature | Complexity | Standalone Value | |-------|---------|------------|------------------| | 1 | Leak detection on outputs | Low | High — catches accidents immediately | | 2 | Plugin secret declarations | Medium | High — foundation for isolation | | 3 | Subprocess sanitization | Medium | Medium — requires careful exec wrapper | | 4 | Encrypted storage (avault) | High | High — but can use existing avault | **Subprocess sanitization is tricky.** Some tools legitimately need credentials (e.g., `git push`, `ssh`). We'd need an allowlist or explicit secret-forwarding mechanism, not blanket stripping. ### Dependencies - **Activity Loop (#49)**: Autonomous plugins running without human oversight makes secret isolation even more critical. These should be designed together. - **Scheduled Execution (#42)**: Cron jobs will need secret access patterns too. ### Security Considerations - Leak detection should cover logs, not just outbound messages - Consider secret rotation/revocation — if a secret leaks, how do we invalidate it? - Plugin trust levels: should core plugins have broader access than third-party ones? ### Suggested Next Steps 1. Start with **Phase 1** (leak detection) as a quick win — simple regex/pattern matching on all output paths 2. Spec out the plugin secret declaration format for Phase 2 3. Evaluate whether avault integration or a simpler file-based approach is right for MVP Happy to help design the `SecretProvider` extension point if this moves forward. This is foundational work that unblocks running untrusted plugins safely. — 🦊

nazim referenced this issue

2026-02-22 07:25:33 +00:00

Define development workflow: personas, ticket lifecycle, and sub-agent templates #52

doxios referenced this issue

2026-02-22 07:28:39 +00:00

Define development workflow: personas, ticket lifecycle, and sub-agent templates #52

Zeus referenced this issue

2026-02-22 07:47:41 +00:00

Define development workflow: personas, ticket lifecycle, and sub-agent templates #52

~~doxios referenced this issue 2026-02-22 07:57:14 +00:00~~

Epic: Development Workflow & Sub-Agent Automation #53

nazim referenced this issue

2026-02-22 10:21:43 +00:00

Plugins have undeclared runtime dependencies — eliminate service locator pattern #57

doxios referenced this issue

2026-02-22 10:23:58 +00:00

Plugins have undeclared runtime dependencies — eliminate service locator pattern #57

nazim referenced this issue

2026-02-22 10:45:42 +00:00

Refactor tool injection: LLM owns the extension point, tools plugin becomes a registry #58

nazim referenced this issue

2026-02-22 11:08:01 +00:00

Create Plugin Design Guide: codify architecture principles for reviewers and designers #59

doxios referenced this issue

2026-02-22 11:18:55 +00:00

Create Plugin Design Guide: codify architecture principles for reviewers and designers #59

nazim referenced this issue

2026-02-22 11:51:54 +00:00

Create Plugin Design Guide: codify architecture principles for reviewers and designers #59

doxios referenced this issue

2026-02-22 11:52:56 +00:00

Create Plugin Design Guide: codify architecture principles for reviewers and designers #59

nazim referenced this issue

2026-02-22 11:57:45 +00:00

[#59] docs: plugin design guide #73

doxios referenced this issue

2026-02-22 13:10:48 +00:00

fix: resolve plugin anti-pattern violations #79

k9ert referenced this issue from a commit

2026-02-22 13:16:48 +00:00

fix: resolve plugin anti-pattern violations (#79)

doxios referenced this issue

2026-02-26 12:32:16 +00:00

Feature: Identity Gate — Enrich inbound messages with sender trust context #92

k9ert referenced this issue

2026-02-27 00:34:59 +00:00

Secrets are exposed to plugins and subprocesses via environment variables #51

noopsec referenced this issue

2026-02-27 13:49:05 +00:00

[Phase 1] Leak Detection: Scan outbound messages for accidental secret exposure [ON HOLD - needs avault integration] #145

doxios added the

Kind/Security

Priority

High

labels

2026-02-27 18:41:06 +00:00

doxios commented

2026-03-06 21:19:52 +00:00

Collaborator

Security/Privacy reviewer: Ben (@webdiverblue) wants to be looped in on any security and privacy findings related to secret management, avault integration, and leak detection. CC alongside @k9ert on all security-relevant updates.

**Security/Privacy reviewer:** Ben (@webdiverblue) wants to be looped in on any security and privacy findings related to secret management, avault integration, and leak detection. CC alongside @k9ert on all security-relevant updates.

doxios referenced this issue from nazim/avault

2026-03-06 22:11:30 +00:00

feat: Real-time leak detection scan endpoint + vault-aware audit trigger #19

Rows
Columns

Secrets are exposed to plugins and subprocesses via environment variables #50

Problem

What we want

Prior art

Impact

Proposed spec: vault plugin

1. New PluginMeta.secrets field

2. vault plugin

3. Registry wiring

4. Environment scrubbing

5. Leak detection (extend existing security plugin)

6. Migration path

Sizing estimate

What this does NOT cover (future work)

Review: Secrets Management

Alignment with Cobot Architecture

Concerns

Dependencies

Security Considerations

Suggested Next Steps

Proposed spec: `vault` plugin

1. New `PluginMeta.secrets` field

2. `vault` plugin

5. Leak detection (extend existing `security` plugin)