Security Architecture
Security Architecture
Section titled “Security Architecture”Agent Isolation
Section titled “Agent Isolation”Each agent runs in its own workspace with its own:
- File system — agents cannot read each other’s files
- Memory — each agent has private memory files
- Credentials — API keys and tokens are scoped per-agent
- Model configuration — different models and cost limits per agent
Agents communicate only through the messaging bus (Telegram/Slack). There is no shared memory or direct process-to-process communication.
Authentication
Section titled “Authentication”Gateway Authentication
Section titled “Gateway Authentication”The OpenClaw gateway uses token-based authentication. Every connection (IDE, node, API client) must present a valid gateway token.
Channel Authentication
Section titled “Channel Authentication”Each messaging channel uses its own authentication:
- Telegram — bot tokens (one per agent)
- Slack — OAuth app with scoped permissions
- Email — OAuth, IMAP, or forwarding (user’s choice)
- GitHub — deploy keys or personal access tokens
User Authentication
Section titled “User Authentication”Users authenticate through their chosen messaging platform. We don’t maintain a separate user database for agent interactions.
Network Security
Section titled “Network Security”Tailscale (Recommended)
Section titled “Tailscale (Recommended)”For multi-gateway deployments, we recommend Tailscale for secure agent-to-agent communication:
- End-to-end encrypted WireGuard tunnels
- No public ports exposed
- Identity-based access control
- Works across cloud providers and home networks
All public-facing endpoints use TLS. Agent-to-agent API calls use HTTPS.
Data Handling
Section titled “Data Handling”What We Store
Section titled “What We Store”- Agent workspace files (SOUL.md, memory, skills)
- Message history (stored by Telegram/Slack, not by us)
- Gateway configuration
What We Don’t Store
Section titled “What We Don’t Store”- User credentials (stored in agent workspaces, encrypted at rest)
- Email content (accessed via user’s own auth, not cached)
- Customer data (processed in-flight, not persisted)
Data Residency
Section titled “Data Residency”Your agents run on infrastructure you control. For managed deployments:
- Default: GCP
northamerica-northeast1(Montreal) - Available: any GCP, AWS, or Azure region
- On-premises: supported for enterprise deployments
Credential Management
Section titled “Credential Management”Credentials are stored in agent workspaces under restricted file permissions (chmod 600). For production deployments, we recommend:
- Google Secret Manager or AWS Secrets Manager for API keys
- Rotating tokens on a regular schedule
- Separate credentials per agent (don’t share tokens)