Skip to content
Arxo Arxo

Detection and Config Coverage

This page explains what openclaw_architecture scans and how detector coverage works in practice.

The metric searches for OpenClaw config in this order (relative to project root):

  1. .openclaw/openclaw.json
  2. openclaw.json
  3. openclaw.config.json

If no config file is found, config-based detectors return evidence that OpenClaw config was not found.

Skill-content detectors scan for SKILL.md files:

  • Recursive walk under project root
  • Maximum depth: 6
  • Symlinks are not followed

The scanner extracts the first section matching:

  • ## Prerequisites
  • ## Install
  • ## Requirements

This section is used by supply-chain and content-risk detectors.

openclaw_architecture includes detector families across four axes:

  • Config Security: gateway auth, token quality, control UI exposure, rate limits, path and credential handling
  • Skill Governance: allowlisting, approval controls, sandbox posture, tool scope and A2A governance
  • Observability: OTel, audit logging, retention, drift/trace controls
  • Supply Chain: skill provenance, integrity, malware indicators, MCP/server pinning, high-risk source controls

For the complete detector contract, see:

  • Runtime network telemetry correlation beyond static/project evidence
  • Dynamic exploit verification or live sandbox execution
  • Full semantic understanding of arbitrary natural-language instructions in all docs
  • Infinite-depth workspace scans (depth is bounded for performance)
  • Markdown heuristics can produce false positives for benign security examples.
  • Non-standard config file names/locations can reduce detector visibility.
  • Highly obfuscated or generated content can hide signals from static scanners.
  • If a detector is disabled, it is marked not applicable and excluded from axis averages.
  1. Confirm one of the expected OpenClaw config paths exists.
  2. Ensure relevant skill docs are in reachable depth and named SKILL.md.
  3. Run arxo metrics registry --registry-format detailed to verify expected keys.
  4. Review low-confidence findings before strict policy enforcement.