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
CLI ReferenceWorkspaces & Teams

Workspaces

A workspace is the top-level container in AgentSecrets. It holds your projects, manages team membership, defines the domain allowlist, and is the unit of zero-knowledge cloud sync. Understanding workspace types and how they behave is important before inviting collaborators.


Personal workspaces

Every account has a personal workspace created automatically at signup. It is tied to your account and intended for solo work. You cannot invite other users to a personal workspace — it exists for solo projects, personal agents, and experimentation that does not need to be shared.

When a project needs to be shared, create a shared workspace or use agentsecrets project invite, which handles the transition automatically.


Shared workspaces

Shared workspaces are created explicitly for team collaboration. The creator is automatically assigned owner and admin roles.

agentsecrets workspace create "Acme Engineering"

All projects, secrets, and the domain allowlist in a shared workspace are accessible to all members with appropriate roles.


Creating a workspace

agentsecrets workspace create "Workspace Name"

After creation, switch to the new workspace and create your first project:

agentsecrets workspace switch "Workspace Name" agentsecrets project create my-service

Listing and switching workspaces

# List all workspaces you belong to agentsecrets workspace list # Switch active workspace agentsecrets workspace switch "Acme Engineering" # To switch to your personal workspace agentsecrets workspace switch personal

All subsequent commands operate in the active workspace.


Inviting team members

agentsecrets workspace invite alice@example.com agentsecrets workspace invite bob@example.com carol@example.com

The invited developer is added to the workspace. When they run agentsecrets login on their machine, they can switch to the workspace and pull secrets directly to their OS keychain — no credential values shared over Slack or email.

Workspace invites only work on shared workspaces. You cannot invite someone to a personal workspace. Use agentsecrets project invite instead, which creates a shared workspace automatically if the project is in a personal one.


Onboarding a new developer

The invited developer runs this on their machine:

agentsecrets login agentsecrets workspace switch "Acme Engineering" agentsecrets project use payments-service agentsecrets secrets pull

Their OS keychain now has all the secrets for that project and environment. Nothing was shared over any channel. The secrets went directly from the encrypted cloud sync to their keychain.


Roles and permissions

Workspaces have two roles: member and admin.

PermissionMemberAdmin
Read secrets (key names)
Pull secrets to local keychain
Push secrets to cloud
Run the proxy
Use all agent-facing features
Modify the domain allowlist
Invite and remove teammates
Change member roles
# Grant admin role (requires admin + password confirmation) agentsecrets workspace promote alice@example.com # Revoke admin role (requires admin + password confirmation) agentsecrets workspace demote bob@example.com

Allowlist modifications require admin role and password confirmation at the time of the change. Even an admin cannot accidentally change the allowlist without an explicit authenticated action.


Revoking access

agentsecrets workspace demote user@example.com

When a developer leaves the team, remove them from the workspace. Their local keychain still holds the secrets they pulled — rotate any sensitive credentials after offboarding. See Rotating a Compromised Credential for the rotation workflow.


Project invites and the personal workspace transition

agentsecrets project invite adds a collaborator to a specific project. Its behavior depends on the workspace the project lives in.

If the project is in a shared workspace, the invite works as expected — the person is added to the workspace and gains access to the project.

If the project is in a personal workspace, inviting someone would expose all of your personal projects and secrets. Instead, AgentSecrets automatically creates a new shared workspace with the same name as the project, moves the project into it, adds you as owner and admin, and adds the invitee.

Your personal workspace is unchanged. The project now lives in an isolated shared workspace accessible only to you and the people you invited.

# You are in your personal workspace agentsecrets status # Workspace: personal (your-username) # Project: payments-service agentsecrets project invite alice@example.com # → Personal workspace detected # → Created shared workspace: "payments-service" # → Moved project to shared workspace # → Added you as owner and admin # → Invited alice@example.com agentsecrets status # Workspace: payments-service (shared) # Project: payments-service

Managing multiple workspaces

agentsecrets workspace list # personal (your-username) ← personal # Acme Eng (shared) 3 members # payments-service (shared) 2 members agentsecrets workspace switch "Acme Eng"

You can belong to and switch between as many workspaces as needed. The active workspace is shown in agentsecrets status.

Was this helpful?
Thanks for your feedback!
Your feedback helps us improve the platform.