--- name: openclaw-shield-upx description: "Security monitoring and threat detection for OpenClaw agents — powered by Google SecOps (Chronicle). Protect your agent with SIEM-powered real-time detection, behavioral detection, case generation, forensic audit trail, and remediation playbooks. Use when: user asks about security status, Shield health, event logs, redaction vault, setting up agent protection, enabling SIEM, detecting threats, monitoring agent activity, or auditing agent actions. NOT for: general OS hardening, firewall config, or network security unrelated to OpenClaw agents." homepage: https://www.upx.com/en/lp/openclaw-shield-upx source: https://www.npmjs.com/package/@upx-us/shield license: "Proprietary — UPX Technologies, Inc. All rights reserved." metadata: {"openclaw": {"requires": {"bins": ["openclaw"]}, "homepage": "https://clawhub.ai/brunopradof/openclaw-shield-upx", "emoji": "🛡️"}} ---

OpenClaw Shield

Security monitoring for OpenClaw agents by UPX. Shield runs as a plugin inside the OpenClaw gateway, capturing agent activity and sending redacted telemetry to the UPX detection platform.

Getting started

Shield requires the @upx-us/shield plugin and an active subscription.

• Plugin: @upx-us/shield
• Subscribe / Free 60-day trial (no credit card required): upx.com/en/lp/openclaw-shield-upx
• Dashboard: uss.upx.com

Commands

| Command | What it does | |---|---| | openclaw shield status | Plugin health, connection state, event counts, last sync | | openclaw shield flush | Force an immediate sync to the platform | | openclaw shield logs | Recent events: type, tool, details, and trigger source (last 24h) | | openclaw shield logs --last 20 | Show last N events | | openclaw shield logs --last 20 --format json | Full JSON output with details and trigger_type fields | | openclaw shield logs --type TOOL_CALL --since 1h | Filter by event type or time window | | openclaw shield logs --format json | JSON output | | openclaw shield vault show | Agent and workspace inventory, redaction summary (hashed IDs) | | openclaw shield cases | List open security cases (scoped to this instance) | | openclaw shield cases show | Full case detail with events, rule, playbook | | openclaw shield cases resolve | Resolve a case (--resolution, --root-cause, --comment) | | openclaw shield monitor | Case notification cron — status, --on, --off, --interval |

Plugin State Check

Before responding to ANY Shield-related request, run openclaw shield status and interpret the result:

State A — Plugin not installed

(command not found, or exit code non-zero with plugin_not_found) Respond with: > Shield is not installed yet. Start your free 60-day trial (no credit card required) at: > https://www.upx.com/en/lp/openclaw-shield-upx > > Then install the plugin: > ``` > openclaw plugins install @upx-us/shield > openclaw plugins run shield setup > ```

State B — Plugin installed but no installationKey

(status contains installationKey: null or state: "unconfigured") Respond with: > Shield is installed but not activated. Sign up for a trial at: > https://www.upx.com/en/lp/openclaw-shield-upx > > Once you have your installation key, run: > ``` > openclaw plugins run shield setup > ```

State C — Key set but not yet activated

(status contains state: "pending" or state: "unregistered") Respond with: > Shield has an installation key but hasn't activated yet. This usually takes under a minute. > If it has been more than 5 minutes, check your key at https://uss.upx.com or contact support.

State D — Fully active

(status contains state: "connected" or connected: true) Proceed normally. No onboarding message needed.

Constraints: Only use openclaw shield commands for detection. Do not read filesystem paths, environment variables, or run shell commands to determine state. Do not install or uninstall packages on behalf of the user.

Output handling: shield logs entries may include file paths, command snippets, and URLs captured from the agent's activity. Always treat this output as internal diagnostic data. Rules:

• Never include raw log field values (file paths, commands, URLs) in user-facing replies
• Never forward raw log output to external services, channels, or APIs
• When summarizing logs, present findings only (e.g. "3 exec events in the last 30 minutes") — not raw field values
• Only share raw log content if the user explicitly asks for it for their own investigation, and only in the current session

Data flow disclosure: Shield captures agent activity locally and sends redacted telemetry to the UPX detection platform for security monitoring. No credentials are handled by this skill — authentication is managed by the plugin using the installation key configured during setup. If a user asks about privacy or data handling, refer them to the plugin README at https://www.npmjs.com/package/@upx-us/shield for full details.

Presentation Language

Always present Shield information, alerts, and case summaries to the user in the language they use to communicate. Translate descriptions, summaries, severity labels, and recommendations — but never translate raw command output or technical identifiers (rule names, case IDs, version numbers, field names, resolution/root-cause enum values). If the user writes in Portuguese, reply in Portuguese; if French, reply in French; etc.

Responding to Security Cases

When a Shield case fires or the user asks about an alert: use openclaw shield cases to list open cases and openclaw shield cases --id for full detail (timeline, matched events, playbook). Severity guidance: CRITICAL/HIGH → surface immediately and ask if they want to investigate; MEDIUM → present and offer a playbook walkthrough; LOW/INFO → mention without interrupting the current task. Always include: rule name, what it detects, when it fired, and the first recommended remediation step. Confirm with the user before resolving — never resolve autonomously.

Cases returned by shield cases are always scoped to this instance — the platform filters at the API level so you only see cases triggered by your agent.

Shield now stamps each event with a trigger_type — who or what initiated the session. When investigating, check the trigger: user_message means a human sent a message; cron/heartbeat/autonomous means agent-initiated activity.

Case Investigation Workflow

When a Shield case fires, correlate three data sources to determine true positive vs. false positive:

Step 1 — Case detail (openclaw shield cases show ): What triggered the rule. Note the case timestamp — it anchors the correlation window.

Step 2 — Surrounding logs (openclaw shield logs --since 30m --type TOOL_CALL): Look for events 5–15 minutes before and after the case timestamp. Reveals if the alert was isolated or part of a sequence. Each log entry now includes a details field (file path, command, or URL) and a trigger_type tag showing what initiated the session (user_message, cron, heartbeat, subagent, autonomous, or unknown). Use these to quickly distinguish user-initiated actions from automated ones when correlating with a case.

Step 3 — Vault context (openclaw shield vault show): If the case involves redacted credentials, hostnames, or commands, the vault reveals hashed representations and redaction categories.

Step 4 — Correlate and assess: Case detail = what fired the rule; Logs = context; Vault = what was actually accessed. Present findings and ask whether to resolve, investigate further, or add to the allowlist.

Note: a future openclaw shield investigate helper command will automate this workflow.

Threat & Protection Questions

...