Windows security model
Native Windows loopback authentication, local audit persistence, credential scope, signing, and operational security boundaries.
Windows enforcement and telemetry are separate paths. A connector's declared synchronous hook, plugin callback, or awaited policy phase can return a decision; native OTLP cannot. Every supported event channel enters an authenticated loopback gateway and then uses the same local audit and optional outbound observability pipeline.
Connector telemetry channels
Each connector page is the canonical place for that agent's hook or policy events, native telemetry support, configuration files, and Windows-only quirks. Keeping those facts beside macOS/Linux setup prevents this platform guide from becoming a second, drifting connector matrix.
The Windows-wide rule is simple: enforcement comes only from the connector's declared synchronous hook, plugin, or awaited policy response. Native OTLP and hook-derived telemetry are observation channels. They can enrich audit and dashboards, but cannot retroactively block an action.
When a connector supports native OTLP, DefenseClaw gives it a separate scoped credential and pins the source identity to that connector. Hook and plugin credentials are also connector-scoped and remain distinct from the gateway master token. Connector pages identify which channels exist and where their managed settings live.
A scoped credential is accepted only for its connector and route; it cannot authenticate the management API, another connector, or a non-loopback request. Hermes hook-derived audit records retain connector, session, event, and correlation attribution before entering generic alert, webhook, OTLP, or Splunk destinations.
Native OTLP is observation-only
A native OTLP log, metric, or trace can enrich audit and dashboards, but it arrives after or beside agent activity. It cannot block a prompt or tool. Only the connector's declared synchronous hook response, plugin callback, or awaited policy phase can enforce action mode.
Local audit is always present
The v8 observability pipeline writes mandatory local SQLite audit data to
%USERPROFILE%\.defenseclaw\audit.db. That local store continues when:
- no remote observability destination is configured;
- the installation is operating without an OpenClaw fleet uplink; or
- an optional remote destination is temporarily degraded.
In the supported standalone hook topology, “gateway disabled” in a fleet row means there is no OpenClaw fleet WebSocket to dial. It does not mean the local hook API, policy evaluation, available native OTLP ingest, local audit, alerts, or TUI have stopped.
gateway.jsonl is not a default audit file. It exists only if an optional
kind: jsonl destination is configured to write that path. The detached
gateway's process log is a different file,
%USERPROFILE%\.defenseclaw\gateway.log.
Privacy and redaction boundary
Supported connector profiles enable source capture of user-prompt facts so the
v8 router can apply destination-specific policy. The fresh v8 redaction profile
is none. Therefore:
- local SQLite can contain unredacted prompt, tool, decision, and telemetry content permitted by the event schema;
- adding an outbound destination does not automatically make its projection safe for a different audience; and
- source-side suppression cannot be assumed to recover content that was never captured.
Treat the data directory and any audit export as sensitive user data. Configure
and verify redaction profiles before routing
records to another system. defenseclaw config show masks secret values by
default. Configuration v8 rejects config show --reveal; do not rely on that
legacy flag in diagnostic workflows.
The gateway records authentication and delivery failures without putting raw scoped credentials into route names or operational telemetry. That does not make a copied database, log, connector configuration, backup, or crash artifact safe to publish.
Credential model
DefenseClaw uses distinct credentials for distinct jobs:
| Credential class | Scope | Operator rule |
|---|---|---|
| Gateway master token | Local gateway control/lifecycle authentication. Stored through the protected DefenseClaw environment file. | Rotate with the CLI; do not edit, print, or pass it on an argv. |
| Connector hook/plugin credential | One connector's hook or plugin API route. | Managed by setup/teardown; never copy its sidecar or the credential-bearing Amp plugin. |
| Connector native-OTLP credential | One connector's OTLP routes where configured: Codex, Claude Code, or opt-in OmniGent. Hermes has no official native OTLP surface. | Stable across unrelated master-token rotation and revoked during connector teardown. |
| Provider or destination credentials | Only the configured external provider/destination. | Reference protected environment names; do not place literal values in YAML or support output. |
Rotate safely
Token rotation is global because the gateway master token and active connector generation must move together:
defenseclaw setup rotate-token --yesThe transaction verifies gateway A, stops that exact owned process, durably
commits the new protected value, starts gateway B, reconciles all active
connectors, reloads their persisted native-OTLP settings, and authentication-probes
each supported signal. A post-stop failure restores the exact prior protected
file and ready gateway generation. --no-restart is intentionally refused,
and an externally managed noncanonical token environment is not rewritten.
Connector-scoped hook and OTLP credentials remain distinct from the master token. The rotation does not expose them and does not turn one connector's credential into a cross-connector credential. Restart every configured agent after a successful rotation so its next hook subprocess uses the reconciled generation; fully exit and relaunch Amp so its next plugin callback uses that generation.
Verify without reading any token:
defenseclaw-gateway status
defenseclaw status
defenseclaw doctorLoopback and network boundaries
The supported connector topology uses the current user's native agent and
gateway on loopback, normally
127.0.0.1:18970. The loopback HTTP receiver is
authenticated; it is not a claim that localhost is inherently trusted.
- A connector-scoped token is restricted by connector, route, signal, and loopback origin.
- Management routes require their own authentication.
- A non-loopback agent-to-gateway deployment is not native Windows-certified.
- Outbound OTLP, Splunk, Galileo, webhooks, and provider calls are independent client connections. Their availability does not expand hook coverage.
- Windows OpenClaw/ZeptoClaw proxy listeners are unsupported.
Do not expose the local API to a LAN merely to make a remote agent work. That changes the tested topology and adds authentication, TLS, firewall, and host ownership requirements this guide does not certify.
Release and installer trust
The current 0.8.10 Windows release trust chain is:
- verify the release's checksum set against its Sigstore certificate and release-workflow identity;
- require the Setup SHA-256 named by that authenticated checksum set;
- require the authenticated provenance to describe the same artifact and signing state; and
- verify that Windows observes the matching Authenticode state; and
- exercise that exact release Setup artifact through the deterministic native Windows x64 matrix. Connector availability and authentic-client evidence remain separate claims.
The deterministic native gate is the certification basis. A separately
configured real-agent run can add upstream smoke evidence, but it is not a
substitute for that gate. In particular, an authenticated Amp turn requires
AMP_API_KEY; the absence or presence of that optional secret does not change
the packaged native Windows support classification.
That artifact trust chain does not fabricate connector evidence. Supported
availability for Codex, Cursor, Devin, Hermes, OpenCode, OmniGent,
Copilot, and Antigravity does not populate validation fields or change
live=false; authentic official-client evidence remains independently gated.
For 0.8.10, the authenticated provenance says unsigned: true and
product_executables_authenticode_signed: false; Windows observes the outer
Setup as NotSigned. The release bytes are therefore authenticated by the
Sigstore-signed checksum set, not by an Authenticode publisher. Do not
expect or claim a Cisco Systems, Inc. Digital Signatures entry.
Local and pull-request artifacts do not carry authenticated production release provenance. Passing their deterministic suites proves code and lifecycle behavior, not that they are a published release artifact.
The native upgrader refuses a missing or invalid authenticated checksum set, digest, provenance, a mismatch between recorded and observed Authenticode state, or an unauthorized Windows source baseline. Its verification bypass is not supported for native Windows. See Install and maintain.
Ownership and filesystem boundary
The public package runs as the current user and owns only exact state it created or recorded. Security-sensitive installer transaction directories, credentials, audit storage, and identity records use current-user ownership, non-reparse checks, and private Windows DACL validation. OpenCode's managed plugin restricts access to the current user, Administrators, and SYSTEM; that limits other standard users but is not tamper-proof against the owning user or an administrator. Doctor detects managed-plugin digest drift, and Setup reconciles it. This is not a blanket claim that every file below every user-selected connector root has an identical DACL.
Setup and lifecycle commands:
- refuse an existing application directory without valid DefenseClaw installer state;
- recheck state identity around live mutation;
- reject unsafe reparse ancestry for protected transaction and recorded connector-home paths;
- stop only a gateway/watchdog whose executable, PID start identity, data root, and protected record agree;
- refuse to replace a foreign HKCU Run value, PATH mutation, Installed Apps record, listener, process, or connector file; and
- retain ambiguous recovery evidence instead of deleting it as cleanup.
Product executables opt into Windows long-path behavior, and installer journals
and process identity are tested beyond legacy MAX_PATH. Do not extrapolate
that guarantee to every third-party agent/plugin. Avoid connector paths that
differ only by case; the product does not advertise case-distinct Windows
connector homes as separate supported identities.
Transaction and fail-closed boundaries
“Fail closed” has several precise meanings:
| Boundary | Proven behavior |
|---|---|
| Setup verification | Invalid architecture, launch identity, authenticated digest/provenance, recorded-versus-observed Authenticode state, payload, path, ownership, or prior state refuses before live mutation where possible. |
| Setup transaction | Pre-commit failure rolls back owned changes; ambiguous or committed phases retain a journal and require safe recovery/convergence. |
| Hook delivery/response | Effective closed blocks only vendor-supported block-capable events for transport and malformed/unauthorized response failures. For OpenCode, only the awaited tool.execute.before thrown-error path is authoritative; after/lifecycle delivery remains best effort. Hermes officially warns and continues for timeout, nonzero exit, malformed output, authentication, and transport failures, so DefenseClaw never claims fail-closed Hermes delivery. |
| Managed enterprise hook | The narrow administrator-managed Claude Code path fails closed when protected policy identity is invalid. |
| Runtime skill selection | A disabled-state database or provenance failure blocks the exact Codex/Claude skill-selection surface. Hermes exposes no equivalent native skill-selection enforcement event. Amp has no separate skill-load callback; its resulting tool calls remain governed at tool.call. |
| Amp plugin initialization | Amp executes plugin top-level code while loading. DefenseClaw enforcement starts only when the managed plugin is loaded and receives tool.call; it does not sandbox sibling plugin initialization or define multi-plugin handler order. |
| Internal evaluator panic | Fails open with warning and telemetry because no authoritative verdict was produced. |
| Optional exporter outage | Local SQLite and healthy gateway operation continue; the destination is reported degraded. |
Malformed v8 configuration prevents strict gateway startup rather than silently
loading legacy semantics. A disabled connector is reconciled out of the active
roster; a persisted change made with --no-restart is reported as desired/runtime
drift until restart.
Administrator-managed Claude Code exception
The public per-user Setup does not install a machine-wide service or enterprise
guardian. A separate, limited gateway command can publish Claude Code managed
hooks for allow-listed interactive users only when the gateway and hook binary
have first been deployed in a protected Administrator/LocalSystem-owned machine
path. A user-writable %LOCALAPPDATA% installation is deliberately rejected as
the elevated command source.
That path does not provide a machine-scope Setup/MSI, general Windows connector guardian, remote gateway, private distribution credentials, or Codex managed hook support. Follow the exact prerequisites in Enterprise deployment.