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

Current Security Limitations (Pre-1.0)

⚠️ Critical limitations to understand before inviting users:

  1. No resource isolation - Any authenticated user can access, modify, or delete any other user’s sessions, tasks, worktrees, and boards. User attribution is tracked but not enforced at the API level.

  2. Shared API keys - API keys configured at the daemon level are visible to all authenticated users. MCP session tokens are stored unencrypted in the database and accessible to any authenticated user.

  3. No rate limiting or quotas - Users can spawn unlimited sessions, make unlimited API calls, and potentially exhaust API credits or system resources.

  4. Admin capabilities - Users with admin role can execute arbitrary code via terminal access and environment controls under the daemon’s system user account.

What IS enforced today:

  • All REST and Socket.io calls require authentication. Anonymous access (when enabled) is downgraded to a read-only viewer role.
  • Privileged endpoints—terminals, environment start/stop, config edits, MCP wiring—require admin permissions. Session/task mutations require at least member permissions.
  • File browsing is restricted to context/ within each worktree, with path traversal guards in place.
  • WebSocket broadcasts only reach authenticated clients; unauthenticated sockets no longer receive canvas or task events.
  • Request body size limits (10MB) prevent DoS attacks via large payloads.
  • Passwords hashed with bcrypt (12 rounds), API keys encrypted with AES-256-GCM.

Important: Formal penetration testing has not been completed. Keep the daemon inside network boundaries you control.

Access Model & Invitations

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)

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.
  • Terminal access and environment orchestration run as the daemon’s underlying system user. Keep the daemon account scoped to the worktree directory and /tmp when possible.

Best practices:

  • Only invite collaborators you trust completely - effectively they have the same access as the daemon’s Unix user.
  • Prefer sandboxed VMs or disposable environments for multiplayer access.
  • Run the daemon as a dedicated Unix user scoped to the Agor directories. Keep SSH/root access separate from day-to-day collaboration.
  • Rotate API credentials frequently and use scoped/temporary credentials where possible.

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.

The Path Forward: Unix User Integration

The real solution to Agor’s multi-user security challenges is OS-level user isolation. We’ve designed a comprehensive approach detailed in our Unix User Integration exploration.

How It Works

Each Agor user gets 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’s API keys stored in their own home directory
  • Audit trail - Process ownership shows who ran what

Implementation Approach

We’re using sudo-based impersonation with progressive enhancement:

  1. Admin setup (one-time): Create Unix users and configure minimal sudo rules
  2. Progressive enhancement: Works without setup (current behavior), better with it
  3. Session spawning: Agent sessions run as the mapped Unix user via sudo -u
  4. Terminal spawning: PTY processes spawn with correct $USER and $HOME

See the full technical design for implementation details, security model, and setup instructions.

Additional v1.0 Security Improvements

Beyond Unix user integration, we’re also planning:

  • Multi-tenancy resource isolation - API-level access controls so users can only access their own resources (or explicitly shared resources)
  • Secure token management - Hash MCP tokens before database storage, add proper expiration enforcement
  • Rate limiting & quotas - Per-user limits to prevent resource exhaustion and API credit abuse
  • Granular permissions - Role-based access controls for worktrees, sessions, and resources

Until these safeguards land, operate Agor with the same caution you would any powerful internal tool—only invite users you trust completely.

Context EngineeringFAQ
BSL 1.1 © 2025 Maxime Beauchemin