Security hardening roadmap: Vault-backed secrets + tool traffic control

[vaayne]

Issue: Security hardening roadmap for Anna

Summary

Track security improvements for Anna with an initial focus on two directions:

1. Introduce a Vault-backed secret management path for storing and retrieving sensitive credentials.
2. Add a proxy/traffic-control layer around tool use so outbound traffic can be observed, constrained, and eventually mediated.

This issue is intentionally exploratory. The goal is to define a security model and implementation plan before building.

Motivation

Anna currently acts as a local AI assistant and gateway daemon. As capabilities expand, the system will likely handle:

• API tokens
• bot credentials
• service secrets
• tool-initiated network requests
• potentially untrusted model/tool outputs

Improving the secret boundary and network control model early should reduce the chance of:

• accidental secret exposure in config, env, logs, or tool output
• overly broad secret access by tools or subprocesses
• uncontrolled outbound traffic
• weak observability around tool/network behavior

Initial directions

1) Vault-backed secret storage

Possible outcomes:

• Store long-lived secrets outside local config files and shell env when possible
• Retrieve secrets just-in-time
• Support auditability and rotation better than plain env/config storage
• Reduce accidental leakage through local files

Questions to answer:

• Which Vault should be supported first?
  • HashiCorp Vault
  • 1Password CLI / Secrets Automation
  • OS keychain abstraction first, Vault later
• What is the fallback path for local development?
• Should Anna cache decrypted secrets in memory? If yes, for how long?
• Which components are allowed to request secrets?
• Should secret access be scoped per tool / per session / per service?

2) Proxy / traffic management around tool use

Possible outcomes:

• Route tool network access through a controllable boundary
• Centralize domain allowlisting / denylisting
• Add request logging / metrics / audit trails
• Support future credential injection at the boundary instead of exposing secrets directly to tools
• Create a place for future leak-detection and egress-policy enforcement

Questions to answer:

• What counts as a "tool use" in Anna's architecture?
  • Pi subprocess calls only
  • built-in integrations (Telegram, future services)
  • all outbound HTTP clients in the codebase
  • subprocesses spawned by tools
• Should this be implemented as:
  • an HTTP(S) proxy
  • an internal Go transport wrapper
  • both (transport wrapper first, proxy later)
• How do we prevent bypass?
• Do we want host allowlists, per-tool policies, or both?
• How should CONNECT / TLS tunneling be handled?

Proposed scope for discovery phase

Phase 1: Threat model

• Define what secrets Anna manages today and will likely manage soon
• Identify current secret entry points, storage locations, and exposure surfaces
• Identify all current outbound network paths
• Define trust boundaries:
  • user config
  • Anna process
  • Pi subprocess
  • external services
  • future tools / extensions

Phase 2: Design options

• Compare secret storage options:
  • env vars
  • file-based encrypted store
  • OS keychain
  • external Vault
• Compare traffic-control options:
  • centralized HTTP client wrapper
  • local proxy
  • subprocess env proxy injection
• Document trade-offs:
  • complexity
  • portability
  • local developer UX
  • observability
  • bypass resistance

Phase 3: Incremental implementation plan

Potential staged rollout:

1. Inventory current secret + network flows
2. Add explicit secret interface in Anna
3. Add pluggable secret backends
4. Add centralized outbound HTTP abstraction
5. Add optional proxy mode for supported tool/network paths
6. Add policy + audit logging
7. Add leak-prevention / redaction hooks where appropriate

Acceptance criteria for this issue

This issue can be closed when:

• A written security design exists for Anna secret handling and outbound traffic control
• One near-term implementation slice is selected
• Follow-up implementation issues are created

Notes

• This issue is for tracking and scoping, not immediate implementation.
• The model should prefer incremental adoption over a big-bang rewrite.
• Strong preference for designs that are easy to reason about and hard to misuse.