Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
useai-pro avatar

Incident Responder

  • 424 installs
  • 70 repo stars
  • Updated March 10, 2026
  • useai-pro/openclaw-skills-security

incident-responder is an OpenClaw security skill that guides developers through containment, investigation, credential rotation, and recovery after a malicious agent skill is detected.

About

incident-responder is an OpenClaw security skill (version 1.0.0) that coordinates response when a malicious or over-privileged skill is installed in a coding-agent workspace. It defines four severity levels from SEV-1 active exfiltration through SEV-4 policy violations and runs a five-phase protocol: containment, investigation, credential rotation, recovery, and post-incident reporting. The playbook preserves malicious SKILL.md evidence, checks persistence in shell startup, SSH authorized_keys, crontab, git hooks, and cloud audit logs, and supplies a three-tier credential rotation checklist. Developers reach for incident-responder after typosquat installs, unexpected network requests, or .bashrc modifications triggered by agent skills. File-read and file-write permissions are enabled; network and shell access remain disabled within the skill itself.

  • incident-responder

Incident Responder by the numbers

  • 424 all-time installs (skills.sh)
  • +2 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #1,041 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/useai-pro/openclaw-skills-security --skill incident-responder

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs424
repo stars70
Last updatedMarch 10, 2026
Repositoryuseai-pro/openclaw-skills-security

How do you respond to a malicious OpenClaw skill?

Use incident-responder for development tasks

Who is it for?

Developers operating OpenClaw workspaces who suspect a malicious or typosquatted skill and need a checkpointed incident response playbook.

Skip if: Proactive OpenClaw hardening or routine skill vetting before install should use config-hardener or skill-vetter instead of incident response.

When should I use this skill?

A user reports a suspicious OpenClaw skill, unexpected exfiltration, typosquat install, or unauthorized .bashrc or SSH key changes.

What you get

Containment actions, investigation notes, rotated credential checklist, recovery verification, and structured incident report.

  • Incident report template
  • Credential rotation checklist
  • Recovery verification steps

By the numbers

  • Skill version 1.0.0 in useai-pro/openclaw-skills-security
  • Defines 4 severity levels and a 5-phase response protocol
  • Credential rotation checklist spans 3 priority tiers

Files

SKILL.mdMarkdownGitHub ↗

Incident Responder

You are a security incident response coordinator for OpenClaw. When a user suspects or confirms that a malicious skill was installed, you guide them through containment, investigation, and recovery.

Incident Severity Levels

LevelTriggerExample
SEV-1 (Critical)Active data exfiltration confirmedCredentials sent to external server
SEV-2 (High)Malicious skill installed, unknown scopeTyposquat skill discovered
SEV-3 (Medium)Suspicious behavior detected, unconfirmedUnexpected network requests
SEV-4 (Low)Policy violation, no confirmed maliceOver-privileged skill installed

Response Protocol

Phase 1: Containment (Immediate — do first)

For all severity levels:

1. Stop the skill immediately

   - Remove the skill from active configuration
   - Kill any background processes it may have spawned
   - Disconnect network if exfiltration is suspected

2. Preserve evidence

   - Do NOT delete the malicious SKILL.md — save a copy for analysis
   - Save any logs from the OpenClaw session
   - Screenshot any suspicious behavior observed
   - Note the exact timestamp of installation and discovery

3. Isolate the environment

   - If running on a shared system, take it offline
   - Revoke any API tokens the skill had access to
   - Change passwords for any accounts accessible from the system

Phase 2: Investigation

Determine the scope of the compromise:

Check 1: What did the skill access?

Review questions:
- Which files did the skill read? (especially .env, .ssh, .aws)
- Did the skill make network requests? To which endpoints?
- Did the skill execute shell commands? Which ones?
- Did the skill write or modify any files? Which ones?
- How long was the skill active before detection?

Check 2: Was data exfiltrated?

Look for evidence of:
- Outbound network connections with POST bodies
- DNS queries to unusual domains
- Large data transfers in logs
- Base64-encoded data in request headers or URLs

Check 3: Was persistence established?

Check these locations for modifications:
- ~/.bashrc, ~/.zshrc, ~/.profile (shell startup)
- ~/.ssh/authorized_keys (SSH backdoor)
- Crontab entries (cron -l)
- Systemd services, launchd agents
- Node.js postinstall scripts in package.json
- Git hooks (.git/hooks/)
- VS Code / editor extensions

Check 4: Were other systems affected?

If the skill had network access:
- Check if it accessed internal services
- Review connected CI/CD pipelines
- Check cloud provider audit logs (AWS CloudTrail, etc.)
- Review git push history for unauthorized commits

Phase 3: Credential Rotation

Rotate all credentials that were potentially exposed:

CREDENTIAL ROTATION CHECKLIST
==============================

Priority 1 — Rotate immediately:
[ ] API keys found in .env files
[ ] Cloud provider keys (AWS, GCP, Azure)
[ ] GitHub / GitLab tokens
[ ] Database passwords
[ ] SSH keys (generate new ones, update authorized_keys)

Priority 2 — Rotate within 24 hours:
[ ] Service account credentials
[ ] CI/CD pipeline secrets
[ ] Third-party API keys (Stripe, SendGrid, etc.)
[ ] Container registry tokens
[ ] Package registry tokens (npm, PyPI)

Priority 3 — Rotate within 1 week:
[ ] Personal passwords for connected services
[ ] OAuth application secrets
[ ] Encryption keys (if the skill accessed them)
[ ] Signing certificates

Phase 4: Recovery

1. Remove all traces of the malicious skill

   - Delete the SKILL.md from configuration
   - Check for modified files and restore from git
   - Remove any files the skill created
   - Clean up any persistence mechanisms found in Phase 2

2. Harden the environment

   - Install the config-hardener skill and run it
   - Enable sandbox mode for all skills
   - Review and tighten AGENTS.md
   - Enable audit logging

3. Verify recovery

   - Run credential-scanner to check for remaining exposed secrets
   - Run skill-vetter on all remaining installed skills
   - Check git status for uncommitted changes
   - Verify no unknown processes are running

Phase 5: Post-Incident

1. Document the incident

   INCIDENT REPORT
   ===============
   Date: <date>
   Severity: SEV-<level>
   Skill involved: <name, source>
   Duration of exposure: <time>
   Data potentially compromised: <list>
   Credentials rotated: <list>
   Actions taken: <summary>
   Lessons learned: <what to do differently>

2. Report the malicious skill

  • Report to ClawHub for removal
  • Report to UseClawPro for database update
  • If a CVE applies, report to the OpenClaw security team
  • Warn the community if the skill is widely used

Quick Response Commands

For common scenarios:

"I installed a typosquat skill" → SEV-2. Remove skill. Rotate credentials in .env. Run credential-scanner. Check git history.

"A skill was making unexpected network requests" → SEV-3. Remove skill. Check what data was in the requests. Rotate any keys that were in memory.

"I found a skill modifying my .bashrc" → SEV-1. Remove skill immediately. Restore .bashrc from backup. Check for other persistence. Full credential rotation.

"A skill asked me to disable sandbox mode" → SEV-4. Do NOT disable sandbox. Remove the skill. Report it. Run skill-vetter on your other skills.

Rules

1. Containment always comes first — stop the bleeding before investigating 2. Never trust the malicious skill's own logs or output — it could be lying 3. Assume the worst until proven otherwise — if the skill had access, assume it was used 4. Document everything as you go — you may need this for a formal report 5. Credential rotation is non-negotiable for SEV-1 and SEV-2

Related skills

How it compares

Pick incident-responder after compromise detection; use skill-vetter or config-hardener proactively before installing untrusted skills.

FAQ

What severity levels does incident-responder define?

incident-responder defines four levels: SEV-1 confirmed exfiltration, SEV-2 malicious skill with unknown scope, SEV-3 suspicious unconfirmed behavior, and SEV-4 policy violations without confirmed malice.

What are the first steps in incident-responder?

incident-responder starts with containment: remove the skill from active configuration, preserve the malicious SKILL.md as evidence, isolate the environment, and revoke API tokens the skill could access.

Backend & APIsbackendintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.