Security

How Autopilot protects your data, isolates agents, and gives you full control over who can do what.

Default Security Model

Autopilot runs with authentication always enabled. On first run, the first human account becomes owner and the rest of access is governed by RBAC roles and scoped API keys.

When you expose your instance to a team or the internet, harden network access and configure roles/permissions. The security model is layered:

1. Network         Who can reach the ports (firewall, VPN, reverse proxy)
2. Authentication  Who is making the request (sessions, API keys)
3. Authorization   What they can do (RBAC roles, permissions)
4. Agent Sandbox   What agents can touch (fs_scope, deny patterns)
5. Secrets         Encrypted at rest, scoped per agent
6. Audit           Every action logged, append-only

Agent Sandboxing

Every agent runs inside a sandbox defined in team/agents.yaml. The sandbox has three layers.

Filesystem Scope

Each agent declares which paths it can read and write:

agents:
  - id: max
    role: developer
    fs_scope:
      read: ["/knowledge/technical/**", "/projects/**"]
      write: ["/projects/*/code/**"]

If an agent tries to read or write outside its scope, the orchestrator returns an access denied error. The CEO agent typically has the broadest scope; individual contributors have narrow scopes.

Hardcoded Deny Patterns

Regardless of fs_scope, these paths are always blocked for all agents:

Even an agent with read: ["/**"] cannot access these paths. Deny patterns are checked before scope evaluation.

Approval Gates

Certain actions require explicit human approval before they execute, configured in team/policies/approval-gates.yaml:

• merge — merging code into protected branches
• deploy — deploying to production
• spend — purchases or API calls above a threshold
• publish — publishing content externally

Agents propose, humans approve. The workflow engine enforces these gates at the right moment in the process. See Primitives for the full list.

Audit Logging

Every authenticated API request is logged to logs/audit/YYYY-MM-DD.jsonl as append-only JSONL:

{"ts":"2026-03-24T14:30:00Z","actor":"founder","actor_type":"human","action":"tasks.create","target":"/api/tasks","source":"dashboard","ip":"192.168.1.10","result":"success"}
{"ts":"2026-03-24T14:30:05Z","actor":"max","actor_type":"agent","action":"knowledge.write","target":"/api/files/knowledge/technical/api.md","source":"internal","result":"success"}
{"ts":"2026-03-24T14:31:00Z","actor":"viewer@co.com","actor_type":"human","action":"secrets.read","target":"/api/secrets","source":"dashboard","ip":"192.168.1.20","result":"denied"}

Audit logs are protected by hardcoded deny patterns — agents cannot read or modify them.

On top of audit logs, every filesystem change by an agent is auto-committed to Git with a 5-second batch window. The full company history is in git log.

Security Skills for Agents

Autopilot ships with two security-focused skills that agents can use during their work:

Security Checklist (skills/security-checklist/)

A comprehensive OWASP-aligned review checklist. Covers input validation, authentication, authorization, secrets management, dependency scanning, and security headers. Available to agents with the reviewer, devops, or developer role.

Incident Response (skills/incident-response/)

SEV-1 through SEV-4 severity classification, response procedures, communication templates, and blameless post-mortem guide. Available to devops and developer roles.

To enforce security review in your workflows, add a security_review step with type: review before merge gates. This ensures agents apply the security checklist before code reaches production.

Next

• Authentication — Better Auth, actor model, RBAC roles and permissions
• Secrets — encryption at rest, master key management, per-agent scoping
• Self-Hosting — network security, Tailscale, reverse proxy, Docker, hardening checklist