Autopilot reads your scan, generates a .drako.yaml pre-configured with your real agents and tools, and starts everything in audit mode. Nothing is blocked until you’re ready.
Init commands
drako init # autopilot (default) — audit-first
drako init --balanced # enforcement active with escape hatches
drako init --strict # maximum governance for enterprise
drako init --manual # full YAML with all sections
drako init --template fintech # start from an industry template
All levels start from the same autopilot base. --balanced and --strict apply progressive overrides on top.
drako init automatically runs a scan if no cached results are found, so you don’t need to run drako scan . separately.
What autopilot generates
Autopilot analyzes your scan results and produces a config with sensible defaults for every policy:
| Policy | Autopilot default |
|---|
| ODD | Each agent locked to its discovered tools, enforcement_mode: audit |
| DLP | mode: audit — logs PII, does not block |
| Circuit Breaker | Threshold 5 failures / 60s window / 30s recovery |
| HITL | Active for write, execute, and payment tools; timeout_action: allow |
| Audit | Enabled, standard (non-cryptographic) logging |
| FinOps | Cost tracking enabled; routing and cache disabled |
For agents with no detected tool assignments, autopilot permits all discovered tools. For agents with explicit tool associations, it sets forbidden_tools for everything outside that set.
Magnitude limits are computed from your project’s agent count, tool count, and model selection. Projects using expensive models (GPT-4, Claude 3 Opus, o1/o3) receive tighter per-action limits.
Upgrade path
Start in audit mode to observe behavior without blocking anything, then upgrade when you’ve reviewed the logs.
Start in autopilot
Everything logs. Nothing blocks. Review audit logs and tune your permitted_tools lists. Upgrade to balanced
Applies these changes to your existing .drako.yaml:| Policy | Change |
|---|
| DLP | audit → enforce (blocks critical PII) |
| ODD | audit → enforce (blocks unauthorized tools) |
| HITL | timeout_action: allow → reject (no-response = block) |
Upgrade to strict
Applies these additional changes:| Policy | Change |
|---|
| HITL | mode → enforce + timeout_action: reject |
| Intent verification | mode → enforce + anti_replay: true |
| Audit | cryptographic: true + retention_days: 90 |
| Magnitude | enforcement_mode → enforce |
Run drako status after upgrading to verify your configuration is valid and in sync with the platform.
Governance levels
| Level | ODD | DLP | HITL timeout | Intent verification | Cryptographic audit |
|---|
| autopilot | audit | audit | allow | off | no |
| balanced | enforce | enforce | reject | off | no |
| strict | enforce | enforce | reject | enforce | yes |
| custom | you decide | you decide | you decide | you decide | you decide |
custom disables the managed upgrade path entirely. Use it when you need full control over every field and don’t want Drako’s upgrade commands to touch your config.
Manual mode
If you prefer to write the config by hand, --manual generates a full YAML with all sections, most commented out:
This produces a governance_level: custom config with every policy section included as comments, ready for you to uncomment and fill in. Use this as a starting point when the autopilot defaults don’t match your project structure.