Security Architecture Overview
The security model is built on four primary pillars that coordinate to ensure that only authorized devices can issue commands and that agents only access the minimum necessary secrets to fulfill a request.- Identity & Pairing: Establishes trust between the daemon and clients (CLI, Desktop, Mobile) using Ed25519 keys and x509 certificates.
- Vault: Provides encrypted storage for API keys and credentials, leveraging OS-native backends like macOS Keychain or Windows DPAPI.
- Policy Enforcement: Uses the Cedar policy language to evaluate every tool call and management action against a set of rules.
- Sandbox Isolation: Executes high-risk tools (like arbitrary shell commands) in multi-tiered sandboxes to prevent lateral movement or filesystem escape.
5.1 Identity, mTLS, and Device Pairing
Thepalyra-identity subsystem manages the Root Certificate Authority (CA) and the lifecycle of device identities. All communication between Palyra components is secured via Mutual TLS (mTLS). Devices pair with the daemon using a TOFU (Trust on First Use) flow where a unique device_id and proof are verified before a certificate is issued.
- Key Entities:
IdentityManager,DeviceIdentity,Ed25519keys. - Pairing: Supports QR codes or manual proof entry via CLI.
- For details, see Identity, mTLS, and Device Pairing.
5.2 Vault: Secret Storage and Credential Management
Thepalyra-vault crate provides a secure abstraction for storing sensitive data. Instead of passing raw API keys in configuration files, Palyra uses “Vault Refs” (e.g., vault://openai/api_key). The vault automatically selects the most secure backend available on the host platform.
| Platform | Backend Implementation | Code Reference |
|---|---|---|
| macOS | Keychain Services | BackendKind::MacosKeychain |
| Linux | Secret Service (libsecret) | BackendKind::LinuxSecretService |
| Windows | DPAPI | BackendKind::WindowsDpapi |
| Fallback | Encrypted SQLite/File | BackendKind::EncryptedFile |
- For details, see Vault: Secret Storage and Credential Management.
5.3 Authentication and Auth Profiles
palyra-auth manages the high-level authentication state for external services (like OpenAI, Discord, or Slack). It handles OAuth2 flows, token refresh logic, and organizes these credentials into “Auth Profiles.” This allows a single Palyra instance to switch between different personas or organizational contexts.
- Core Concepts:
AuthProfileRegistry,SessionManager, OAuth token persistence. - Integration: Connects the
palyradgateway to thepalyra-vaultfor secure token storage. - For details, see Authentication and Auth Profiles.
5.4 Tool Approvals and Access Control
Palyra uses a “Human-in-the-loop” model for high-risk operations. Thepalyra-policy engine, powered by Amazon Cedar, evaluates every action. If an action is marked as sensitive (e.g., process_exec or filesystem_write), the system pauses execution and generates an ApprovalRequest.
Policy Evaluation Logic
- Decision Types:
Allow,Deny, andDenyByDefault(which triggers the approval flow). - Capability Scopes:
ProcessExec,Network,SecretsRead, andFilesystemWrite. - For details, see Tool Approvals and Access Control.