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 policies such as model access, command permission rules, sandbox rules, and managed hooks can be applied across laptops, CI, VMs, and airgapped environments.

Command controls#

Droid evaluates shell commands against permission rules. Each rule matches an exact, ordered command prefix and includes examples that verify its matching behavior.

Organization rules claim repeated IDs before lower-priority definitions. Rules with different IDs accumulate, and matching blocks take precedence over requests for approval, which take precedence over allows. Commands with no policy match fall back to normal approval handling.

Configure rules through Enterprise Controls or the permissionRules setting. Use droid rules check --command 'git push origin main' to preview command policy without executing the command.

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.