What is AgentSecrets?
The Zero-Knowledge Difference
How AgentSecrets Works
Installation
Quick Start
Migrating from .env Files
Migrating from Vault / AWS
Migrating from dotenv-vault
Production Checklist
Credential Exposure
What Zero-Knowledge Means
The Proxy Model
The Three-Layer Model
Environments
Agent Identity
Storage Modes
The No get() Principle
Secret-Level Policies
Cloud Overview & Architecture
The Dual-Engine Model
Cloud Resolver Data Plane
Workload & Agent Tokens
Egress Allowlists & Audit Streams
Cloud REST API Reference
Account (init / login)
Server & Self-Hosting (server)
Docs
Shell Autocompletion
Keychain Auth
Secrets
Environments
Credential Proxy
env Injection
Workspaces & Teams
Projects
Agent Identity
Audit & Governance
Integrations Overview
Claude Desktop
Cursor
OpenClaw
HTTP Proxy (Any)
LangChain (Soon)
CrewAI (Soon)
CI/CD Pipeline
SDK Overview
Python SDK
Python API Reference
Python SDK Manual Testing
JavaScript SDK (Soon)
Ecosystem Overview
Zero-Knowledge MCP Server
Server Overview
5-Layer Architecture
Self-Hosting Guide
Authentication & Keys
Workspaces & Teams
Projects & Scope
Environments
Secrets & Sync Protocol
Agent Identity Resolution
Telemetry & Metrics Engine
Audit Log Sync
API Endpoint Reference
Security Overview
Anti-Impersonation & Process Verification
Encryption Model
Zero-Knowledge Sync
Proxy Security Layers
Threat Model
OWASP Top 10 Mitigation
Security FAQ
Third-Party Audit
Reporting Vulnerabilities
Guides Overview
Building on the SDK
Stripe Integration
OpenAI Integration
Multi-Agent Setup
Onboarding Team
CI/CD Pipeline
Publishing ZK MCP
Rotating Credentials
Auditing Team Activity
Dev to Production
Kubernetes Deployment
Monorepo Setup
Production Proxy Hardening
vs .env Files
vs HashiCorp Vault
vs AWS Secrets Manager
vs dotenv-vault
vs Infisical
When Not to Use
Proxy Not Starting
Proxy Not Resolving
Domain Blocked
Sync Conflicts
MCP Not Connecting
Session Token Errors
Proxy Session Authorization
Keychain Storage & Backends
SSRF & Destination Rules
Installation Issues
Error Codes Reference
Frequently Asked Questions
v3.1.x
v3.0.0
v2.1.0
v2.0.0
v1.4.0
v1.3.x
v1.2.0
v1.1.x
v1.0.x
Fundamental ConceptsStorage Modes

Storage Modes

AgentSecrets supports two local storage modes that determine where decrypted secret values are stored on your machine. You choose a mode when you initialize a project using agentsecrets init, which is saved in .agentsecrets/project.json.


What Storage Modes Cover

It is important to distinguish what storage modes control:

  • Decrypted Secrets: The storage mode only affects where secrets pull writes decrypted secret values on your machine (e.g. only in the OS Keychain vs also written to a .env.{environment} file).
  • System Credentials (Always Keychain-Stored): In v3.0.0, user authentication JWT tokens (access and refresh tokens) and decrypted workspace keys are always stored securely in the native OS Keychain (macOS Keychain, Windows Credential Manager, or GNOME Keyring/KWallet on Linux). Plaintext files like token.json and config.json on disk are kept stripped of any sensitive credentials, ensuring a zero-disk security baseline regardless of the chosen storage mode.

In keychain-only mode, secrets live exclusively in your OS keychain. No .env files are created or read.

agentsecrets init --storage-mode 1

How it works:

  • secrets set → writes directly to OS keychain and syncs encrypted blobs to cloud.
  • secrets push → reads from OS keychain, encrypts, and uploads to cloud.
  • secrets pull → downloads from cloud, decrypts, and writes to OS keychain.
  • secrets pull also generates .env.example containing key names and environment annotations, never values.

Security Benefit: Any process running as the same user can read a file on disk. An AI agent with filesystem access can read .env files. The OS keychain has a fundamentally different security boundary, and other processes cannot read keychain entries without explicit authorization. Keychain-only mode means there are no secret values on disk for an agent to find.

Use Mode 1 for any project where an AI agent has filesystem access to the project directory, for all production environments, and whenever you want the strongest possible local security boundary.


Mode 2: Keychain and .env File

In Mode 2, secrets are stored in the keychain and also written to .env.{environment} files when you pull.

agentsecrets init --storage-mode 2

How it works:

  • secrets set → writes directly to OS keychain and syncs encrypted blobs to cloud.
  • secrets push → reads from .env.{current_environment} (falls back to .env), encrypts, and uploads to cloud.
  • secrets pull → downloads from cloud, decrypts, and writes to both the OS keychain and a .env.{environment} file.
  • The .env.{environment} file is a convenience output of pull; the keychain remains the local source of truth.

Security Considerations: Mode 2 creates .env.{environment} files on disk containing plaintext values after each pull. Though Mode 2 automatically adds these files to your .gitignore, ensure they are never committed to your repository. Do not use Mode 2 in projects where an AI agent has filesystem access to the project directory.


Mode 1 vs Mode 2 Summary

FeatureMode 1: Keychain OnlyMode 2: Keychain + .env
Decrypted secrets on diskNeverYes — .env.{environment} after pull
Agent filesystem access riskNonePresent
Framework .env compatibilityRequires proxy or agentsecrets envNative
Recommended for productionYesWith caution
Recommended when agent has filesystem accessYesNo
.env.example generatedYes (names only, no values)Yes (names only, no values)
Session tokens & workspace keys on diskNever (Keychain-stored)Never (Keychain-stored)
Was this helpful?
Thanks for your feedback!
Your feedback helps us improve the platform.