Security

Security

Agor is still pre-1.0. Given the early stage of the project, we recommend you keep Agor within trusted networks and provide access only to users you’d be confident giving the daemon’s direct user access to the machine.

Security audit conducted using Agor itself - parallel sessions across Claude, Codex, and Gemini

Security Status (v0.5+)

✅ Now Available: RBAC and Unix Isolation

Agor now supports three security modes for multi-user deployments:

  1. Simple Mode (Default) - Open access, best for trusted teams
  2. Insulated Mode - Worktree-level isolation with Unix groups
  3. Strict Mode - Full per-user isolation with process impersonation

See Multiplayer Mode with Unix Isolation for complete setup guide.

What IS enforced today:

  • ✅ Authentication - All REST and Socket.io calls require authentication. Anonymous access (when enabled) is downgraded to read-only viewer role.
  • ✅ Role-based authorization - Privileged endpoints (terminals, environment controls, config) require admin permissions. Session/task mutations require at least member permissions.
  • ✅ Worktree RBAC (Optional) - When enabled, enforces ownership and permission levels (view/prompt/all) at API and filesystem level.
  • ✅ Unix isolation (Optional) - Process impersonation and Unix groups provide OS-level security boundaries.
  • ✅ Path traversal protection - File browsing restricted to context/ within each worktree with traversal guards.
  • ✅ Encrypted credentials - Passwords hashed with bcrypt (12 rounds), API keys encrypted with AES-256-GCM.
  • ✅ Request limits - Body size limits (10MB) prevent DoS via large payloads.

Current Limitations (Pre-1.0):

  • ⚠️ Default is open access - RBAC/Unix isolation must be explicitly enabled
  • ⚠️ No rate limiting or quotas - Users can spawn unlimited sessions (configurable limits planned)
  • ⚠️ Admin capabilities - Users with admin role have extensive system access
  • ⚠️ No formal penetration testing - Keep daemon inside trusted network boundaries

Important: While RBAC and Unix isolation are production-ready, formal security auditing is ongoing. Operate Agor with the same caution you would any powerful internal tool.

Access Model & Security Modes

Default Mode (Simple)

In default configuration, treat every invited user as having:

  • Full read/write access to all Agor data (sessions, tasks, worktrees, boards)
  • Access to all configured API keys (Claude, Codex, Gemini)
  • Ability to execute code as the daemon’s Unix user (if admin role)

With RBAC Enabled (Insulated/Strict Modes)

When execution.worktree_rbac: true, users have:

  • ✅ Isolated worktree access - Can only access worktrees they own or have permission to
  • ✅ Per-user API keys - Each user configures their own API credentials
  • ✅ Filesystem isolation - Unix groups enforce worktree boundaries
  • ✅ Process isolation (Strict mode) - Sessions run as the user’s Unix account

Authentication & Authorization:

  • Users authenticate with JWTs generated by the daemon. Roles (viewer, member, admin, owner) control which privileged endpoints they can access.
  • Anonymous mode (if explicitly enabled) maps to a read-only viewer role—no session creation, terminals, or environment controls.
  • With RBAC enabled, worktree ownership determines access to sessions, tasks, and files.
  • Strict mode adds process-level isolation via Unix user impersonation.

Best practices:

  • Enable RBAC for shared environments - Provides API and filesystem isolation between users
  • Use Strict mode for production - Maximum isolation with full audit trail
  • Prefer sandboxed VMs or disposable environments for multiplayer access
  • Run the daemon as a dedicated Unix user scoped to the Agor directories
  • Rotate API credentials frequently and use scoped/temporary credentials where possible
  • Monitor /var/log/auth.log for sudo activity in Unix isolation modes

Deployment Guidance

  • Keep the daemon behind a firewall, VPN, or private network. Pair it with reverse proxies if you need SSO or IP allowlists.
  • Harden the host like any shared dev box: patch regularly, monitor logs, and rotate credentials.
  • If internet exposure is unavoidable, prefer open-source projects only and rotate API keys frequently.

API Keys & Secrets

  • Agent API keys configured in the daemon remain visible to admin users (and potentially compromised hosts). Load only what you need, monitor usage, and rotate aggressively.
  • Prefer scoped or temporary credentials and keep secrets out of repositories.
  • Consider de-elevating the daemon user further (e.g., dedicated VM + short-lived keys) when handling sensitive code.

Encryption master secret

Agor encrypts stored credentials (Claude/Codex/Gemini API keys, MCP tokens, etc.) when the daemon starts with a master secret. Set the AGOR_MASTER_SECRET environment variable before launching agor daemon start.

  • Generate a strong value (32+ random bytes). Example: openssl rand -hex 32.
  • Export it in your shell or process manager:
# ~/.bashrc, ~/.zshrc, or systemd Environment directive
export AGOR_MASTER_SECRET="$(openssl rand -hex 32)"
  • On Windows PowerShell:
$env:AGOR_MASTER_SECRET = [System.Convert]::ToHexString((1..32 | ForEach-Object { Get-Random -Maximum 256 }))
agor daemon start

If the variable is missing, Agor falls back to plaintext storage and logs a warning at startup. Production and shared environments should always supply AGOR_MASTER_SECRET.

Per-user secrets & trust boundaries

Edit user settings modal showing agent API keys and environment variables per user

  • Per-user API keys and environment variables live in each user’s profile (Settings → User). They are encrypted at rest with the master secret and only surface in the UI during entry.
  • Despite encryption, the daemon still hosts all secrets; a malicious admin (or compromised host) could recover them. Invite only collaborators you trust with your tool credentials.
  • Application admins can rotate or revoke keys quickly. Encourage teammates to manage their own secrets instead of sharing tenant-wide tokens.

Codespaces Notes

  • GitHub Codespaces only forwards ports to the Codespace owner by default, which helps when you’re the only user.
  • The moment you open those ports publicly, treat the environment as compromised: API keys, repository contents, and in-progress work can leak.
  • Combine Codespaces with the guidance above—keep it behind authentication, and prefer non-sensitive workloads if you need to collaborate in a Codespace.

RBAC and Unix Isolation (Available Now)

Multi-user security is here! Agor now provides OS-level user isolation with worktree-centric RBAC.

How It Works

Each Agor user can get their own Unix user account (e.g., agor_alice, agor_bob):

# Alice opens terminal in Agor UI
$ whoami
agor_alice
 
$ pwd
/home/agor_alice
 
# Her credentials are isolated
$ ls ~/.ssh/
id_ed25519  id_ed25519.pub  # Only Alice can read these

Benefits:

  • ✅ True credential isolation - Each user has their own $HOME with separate SSH keys, GitHub tokens, and API credentials
  • ✅ Proper file ownership - Files created reflect the actual user identity
  • ✅ OS-enforced security - Unix permissions naturally prevent cross-user access
  • ✅ Per-user API keys - Each user manages their own API credentials
  • ✅ Audit trail - Process ownership shows who ran what (ps aux, /var/log/auth.log)
  • ✅ Worktree isolation - Unix groups enforce filesystem boundaries

Three Security Modes

  1. Simple Mode (Default) - No isolation, all runs as daemon user

    • Best for: Personal use, trusted teams, quick start

  2. Insulated Mode - Worktree groups + single executor user

    • Best for: Shared development, filesystem protection
    • Requires: Sudoers configuration

  3. Strict Mode - Full per-user isolation with process impersonation

    • Best for: Production, compliance, maximum security
    • Requires: Sudoers configuration + Unix user per Agor user

Get Started

See the complete guide: Multiplayer Mode with Unix Isolation

Quick start:

# ~/.agor/config.yaml
execution:
  worktree_rbac: true # Enable RBAC system
  unix_user_mode: insulated # or strict

Then follow the setup guide to configure sudoers and create Unix users.

Roadmap: Additional v1.0 Improvements

Beyond the implemented RBAC and Unix isolation, we’re planning:

  • Rate limiting & quotas - Per-user limits to prevent resource exhaustion
  • Enhanced audit logging - UI for viewing security events
  • Secure token management - Additional MCP token security hardening
  • Resource usage tracking - Monitor API costs and system resources per user

With RBAC and Unix isolation enabled, Agor provides production-grade multi-user security. For maximum isolation, use Strict mode with dedicated Unix users.

Agor AnnouncementFAQ
BSL 1.1 © 2026 Maxime Beauchemin