Agent Safety & Controls

Factory treats LLMs as powerful but untrusted components. Droid's safety model combines deterministic controls that do not depend on model behavior with Droid Shield secret scanning for git commit and push operations. Even a frontier model operating with high autonomy stays inside the boundaries you set.

Two layers of safety

Build enterprise security primarily on deterministic controls. They are configured through Enterprise Controls & Managed Settings, so hard policy controls such as model access, command blocklists, sandbox rules, and managed hooks apply consistently across laptops, CI, VMs, and airgapped environments.

Command controls

Droid evaluates every shell command it proposes against three lists, all defined in managed settings and accumulated across levels (org entries can never be removed by projects or users):

The blocklist is the hard stop. Before matching, Droid resolves the actual program being invoked, so a blocked command cannot be bypassed with a wrapper shell, an absolute path, quoting tricks, or command substitution. Use it for organization-mandated prohibitions; use the denylist for commands that need a human in the loop, and the allowlist to pre-clear safe, common commands.

{
  "commandAllowlist": ["npm *", "pnpm *", "make *"],
  "commandDenylist": ["sudo *", "rm -rf *"],
  "commandBlocklist": ["mkfs", "shutdown", "curl"]
}

Command risk is also emitted via OTEL, so security teams can monitor how often high-risk commands are proposed or attempted.

Hooks

Hooks are Droid's programmable enforcement and observability interface: they run your own code at defined points in the agent loop. There are nine hook events:

There are no separate "pre-git", "pre-command", or "post-edit" hooks. Those are PreToolUse and PostToolUse hooks scoped with a matcher that selects which tools (or command patterns) the hook applies to.

A hook controls the agent through its output. PreToolUse hooks can return a permissionDecision of allow, deny, or ask. More broadly, hook output can set decision (block or approve), continue, suppressOutput, a systemMessage, and structured hookSpecificOutput. This lets you, for example, block direct git push operations and redirect developers to internal PR tooling, or forward prompts and file snippets to a DLP or CASB API and deny operations that violate policy.

See the Hooks Guide for the full event payloads, matcher syntax, and output schema.

Sandboxing

Droid includes a built-in sandbox that isolates command execution and file access, so you can grant more autonomy without exposing the host. Configure it under the sandbox setting:

{
  "sandbox": {
    "enabled": true,
    "mode": "per-command",
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"],
      "denyWrite": ["/etc"]
    },
    "network": {
      "allowedDomains": ["api.github.com", "registry.npmjs.org"]
    }
  }
}

Sandboxing is a first-class product feature, not just a recommendation to run Droid inside Docker. You can still combine it with external devcontainers or VMs for defense in depth, and tag OTEL sessions by environment (for example, environment.type=local|ci|sandbox) for environment-specific dashboards and alerts.

Network controls

The built-in sandbox controls command-level network egress, while Enterprise Controls can also restrict which client IPs may access Factory APIs and applications.

Use sandbox network rules and corporate proxies for outbound restrictions. Use networkPolicy.allowedIps to reduce where authenticated Factory requests can originate.

Droid Shield: git secret scanning

Droid Shield (enableDroidShield) scans staged diffs before git commit and git push. It blocks the command when it detects likely secrets, and it fails closed when a diff is too large to scan safely.

For detection behavior, false positives, and recovery steps, see Droid Shield.

Use hooks when you need custom DLP, approval workflows, prompt inspection, or calls to internal security systems. Org admins can enforce Droid Shield and managed hooks at the org or project level; users cannot disable controls that are locked by those settings.

Steering as a complement

Deterministic controls are the foundation; LLM steering reduces how often dangerous actions are even proposed. Org and project settings can define rules and instructions (security guidelines and coding standards applied to every request), standardized commands and workflows (for example, /security-review), and context enrichment through allowlisted MCP servers so models work from accurate information. Because these are instructions, not enforcement, they complement rather than replace the hard boundaries above.

For the full schema behind every control on this page, see Enterprise Controls & Managed Settings.