Enterprise deployment

Is this for you?

• One person, one computer: use the open-source install. You install DefenseClaw for yourself, and you own it: you can change its policy or turn it off. Start with the Quickstart.
• A fleet your IT team manages: use enterprise deployment. An administrator or an MDM installs DefenseClaw as operating-system services, and the people who run AI agents, and the agents themselves, cannot turn it off.
• What you need: an MDM, configuration-management tool or administrator shell that runs commands as SYSTEM on Windows and as root on Linux and macOS, and agents that run as standard users.

Which features each edition offers is in the feature table, and which agents are protected on which OS in the enterprise route table.

How enterprise deployment differs

A normal DefenseClaw install belongs to the person who runs the AI agent. That person can stop it, edit its policy, or remove its hooks. Enterprise deployment moves DefenseClaw out of their reach. An administrator or an MDM installs it as operating-system services. The services, the policy, and the program files belong to the administrator. The AI agent still runs in the user's session and its hooks still call DefenseClaw. But the user, and any agent that user runs, can no longer turn the protection off.

In the config this is deployment_mode: managed_enterprise (managed_enterprise).

Two profiles

A managed deployment runs in one of two profiles. Pick the one that matches how you deploy software.

Rules that apply to both:

• One profile per computer. The two profiles use the same gateway port, and on Windows the same service names. Uninstall one before you install the other. The standalone lifecycle refuses to install over a Secure Client deployment.
• The profile is fixed at install. The config sets enterprise.profile, and every service is started with DEFENSECLAW_ENTERPRISE_PROFILE set to the same value. If they disagree, the service refuses to start. To change profile, uninstall one and install the other.
• The default depends on the OS. When neither is set, Windows and macOS resolve to secure_client and Linux resolves to standalone. Linux rejects secure_client. For a standalone deployment on Windows or macOS, always set enterprise.profile: standalone in the config.

The rest of this section covers the standalone profile.

What runs where

Every endpoint runs the same four services. The gateway decides on each tool call and runs as a restricted service account. The guardian installs and repairs each user's hooks. The enumerator finds the users to protect. The sensor helper answers a fixed set of privileged discovery questions for the gateway. The hook (defenseclaw-hook) is not a service: it is an administrator-owned program that the agent runs as the user.

The diagram shows how a tool call gets checked and who puts each piece in place. The enumerator and the sensor helper are in the table below it.

The services and their identities on each OS:

The guardian reconciles every minute and the enumerator runs every five minutes on every OS. The gateway listens only on 127.0.0.1:18970. On Linux and macOS, hooks and DefenseClaw's in-agent plugins reach the gateway only through its local hook socket (/run/defenseclaw-hook/hook.sock on Linux, /opt/cisco/defenseclaw/run/hook.sock on macOS), which tells the gateway each caller's uid; there is no TCP fallback. On Windows they use the loopback address with credentials bound to the user's SID.

The same parts mapped to the trust zones:

Inside the Z3 folders, the gateway account writes only its own data, log and socket folders (for example runtime). Everything else there is written by administrators and DefenseClaw's privileged services.

The full layout of each OS is on its install page: Windows, Linux, macOS.

Who can change what

An AI agent that a prompt can steer has exactly the rights of the user it runs as.

DefenseClaw does not defend a computer from its own administrators. An agent that runs with unrestricted sudo or administrator rights is an administrator.

What a standard user cannot do

• Stop, disable, or reconfigure a DefenseClaw service, or replace one of its programs.
• Edit the config, policies, secrets, target manifest or authorization ledger, or read the Cisco AI Defense key.
• Remove DefenseClaw's hooks from vendor machine policy, or tell the agent to skip them where DefenseClaw sets the vendor's managed-hooks-only lock. Which agents get the lock on which OS is on Machine policy.
• Keep a user or project hook that could rewrite a tool call after DefenseClaw checked it, for the agents the foreign-hook guard covers.
• Pose as the gateway. The hook sends nothing until the operating system shows that the listener is the DefenseClaw service (peer verification).
• Run a second, per-user DefenseClaw. On a managed computer the per-user installer, defenseclaw upgrade, and the per-user gateway refuse to run.

A user can still edit or delete files they own, such as a per-user hook registration. The guardian repairs DefenseClaw's entries on its next pass. Vendor machine policy has no such window. The threat model has the full list and the risks that remain.

Supported platforms and agents

Details are under Requirements on each install page: Windows, Linux, macOS.

DefenseClaw protects each agent through vendor machine policy, a per-user hook the guardian maintains, or the ACP guard. The routes for each agent are in step 2 of Deploy to a fleet, and the agent and OS combinations verified in this release are in the enterprise route table.

OpenClaw and ZeptoClaw are not supported in enterprise deployments. OpenHands and OmniGent are refused on Windows. The per-OS details, including which vendor locks DefenseClaw sets, are on Machine policy. Agent versions and setup are on each connector page.

A minimal config

The administrator config is one YAML file. The example below protects Codex and Claude Code in observe mode, so policy verdicts do not block yet, and installs as written with ensure --config. rule_pack_dir: "" selects the rule packs built into the gateway; to use your own, see Custom rule packs.

config_version: 8
deployment_mode: managed_enterprise
data_dir: /var/lib/defenseclaw          # must be exactly this path
policy_dir: /etc/defenseclaw/policies
enterprise:
  profile: standalone
gateway:
  api_bind: 127.0.0.1
  api_port: 18970
guardrail:
  enabled: true
  rule_pack_dir: ""                     # use the built-in rule packs
  mode: observe                         # observe | action
  connectors:
    codex: {}
    claudecode: {}

config_version: 8
deployment_mode: managed_enterprise
data_dir: /opt/cisco/defenseclaw/runtime   # must be exactly this path
policy_dir: /opt/cisco/defenseclaw/etc/policies
enterprise:
  profile: standalone
gateway:
  api_bind: 127.0.0.1
  api_port: 18970
guardrail:
  enabled: true
  rule_pack_dir: ""                        # use the built-in rule packs
  mode: observe                            # observe | action
  connectors:
    codex: {}
    claudecode: {}

config_version: 8
deployment_mode: managed_enterprise
# Leave data_dir unset: the services use C:\ProgramData\Cisco\DefenseClaw\runtime.
enterprise:
  profile: standalone
gateway:
  api_bind: 127.0.0.1
  api_port: 18970
guardrail:
  enabled: true
  rule_pack_dir: ""                        # use the built-in rule packs
  mode: observe                            # observe | action
  connectors:
    codex: {}
    claudecode: {}

Four things to know before you deploy it:

• Nothing is protected until you list agents. Each key under guardrail.connectors turns on one agent. On Linux and macOS, the config the lifecycle writes when you supply none lists no agents, so it protects nothing. On Windows, install and ensure require a config. On Linux and macOS, naming Codex, Claude Code, Cursor, GitHub Copilot or OpenCode anywhere under guardrail.connectors (even with enabled: false) or under enterprise.machine_policy.connectors makes the lifecycle publish DefenseClaw's hook in that agent's machine policy; on Windows that rule applies to Copilot and OpenCode. To leave an agent unprotected, leave it out of both maps or set its ownership: "off". See Choose the agents to protect.
• Observe mode does not block on policy verdicts. In observe mode DefenseClaw records each decision, including what it would have blocked. Switch guardrail.mode to action to enforce. The deployment's own checks apply in both modes: a tool call is still refused while an unapproved foreign hook is present (with foreign_hooks: remove), or when the user is not enrolled where enrollment is enforced.
• The data directory is fixed. On Linux and macOS the lifecycle rejects any other data_dir. On Windows, a data_dir other than the runtime directory is rejected too.
• Tell enrollment about unusual layouts (Linux and macOS). Users are enrolled from homes under /home and /var/home (Linux) or /Users (macOS), and agent CLIs are found in the usual install locations. If homes live elsewhere, such as /srv/home, list the parent folders under enterprise.enrollment.home_roots; if agents are installed under an administrator prefix, such as an npm --prefix of /opt/tools, list it under enterprise.enrollment.agent_prefixes. See Enrollment.

Where the file goes on each OS, every enterprise.* setting, and the proxy settings are on Configuration.

The optional Cisco AI Defense key never goes in the config: store it after the install, as Cisco AI Defense key shows.

Next steps