Token导航 LogoToken导航TokenDH.com
开发敏感数据clawhub未标认证来源可访问clear审计提醒

skill-privacy-guard技能隐私卫士

Agent Skill

skill-privacy-guard 用于补充开发相关能力,适合在 OpenClaw 中需要让 Agent 承接开发相关任务时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

2,046

周安装

87

GitHub Stars

公开资料未说明

下载量

717
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:skill-privacy-guard(技能隐私卫士)
来源仓库:https://github.com/zhanggroot7/skill-privacy-guard
安装命令:
openclaw skills install skill-privacy-guard
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install skill-privacy-guard

简介

skill-privacy-guard 阻止敏感信息进入技能文件防止泄露风险。

  • 自动屏蔽用户名、路径与个人数据等关键字段。
  • 在创建或更新技能时实时执行隐私过滤动作。skill-privacy-guard 属于开发类 Skill,可作为该场景下的辅助能力补充。
  • 过滤规则可自定义但默认覆盖常见高危模式集合。
  • 建议定期审计过滤日志确保无重要信息被误删。

SKILL.md

name
skill-privacy-guard
description
STOPS all sensitive information from entering skill files. Automatically blocks usernames, paths, personal data when creating or updating skills. CRITICAL - highest priority.
user-invocable
false
disable-model-invocation
false
priority
1

Skill Privacy Guard

PREVENTS sensitive information from entering skill files. Acts as a security gate that blocks personal data, ensuring all skills remain generic and shareable.


Trigger Conditions

AUTO-TRIGGER after:

  • Creating a new skill file
  • Editing/updating any skill.md file
  • User explicitly requests sanitization with keywords: "sanitize", "remove sensitive info", "clean skill"

CRITICAL: This skill has TOP PRIORITY. Always run after skill modifications.


What to Remove

1. Absolute Paths & File Systems

Replace OS-specific absolute paths with generic notation:

PatternReplace With
C:\Users\{username}\~/
/home/{username}/~/
/Users/{username}/~/
C:\Users\{username}\.claude\~/.claude/
D:\Projects\myproject\~/projects/example/
/var/www/mysite//var/www/example/

2. Usernames & Identifiers

Replace actual usernames with generic placeholders:

ContextReplace With
File pathsalice, bob, user
Profile names{username} placeholder
Session examplesGeneric names
Employee IDsEMP-12345
User IDsuser-id-123

3. Network & Infrastructure

CRITICAL - Block all network identifiers:

  • IP Addresses192.0.2.1 (TEST-NET-1), 10.0.0.1 (generic private)
  • MAC Addresses00:00:00:00:00:00 or {MAC}
  • Hostnamesserver1.example.com, host.local
  • Ports with context8080 (generic), avoid specific service ports
  • Internal domains.example.com, .local
  • VPN endpointsvpn.example.com
  • Load balancer IPslb.example.com

4. Credentials & Secrets

NEVER INCLUDE - Remove immediately:

  • API keys (AWS, Google, etc.)
  • Access tokens (Bearer, OAuth)
  • Passwords, passphrases
  • Private keys (SSH, SSL/TLS)
  • Certificates
  • Session tokens, cookies
  • Database passwords
  • Encryption keys
  • JWT tokens
  • Service account credentials
  • SSH fingerprints

5. Database & Connection Strings

Sanitize all connection information:

  • Connection strings → Use placeholder format
  • Database names → example_db, myapp_prod
  • Table names → users, products (generic)
  • Schema names → public, main
  • Redis/Cache endpoints → redis.example.com:6379

Example:

Before: mongodb://admin:pass123@10.1.2.3:27017/mycompany
After:  mongodb://{user}:{pass}@{host}:{port}/{database}

6. Personal Information (PII)

Remove or genericize:

  • Real email addresses → user@example.com
  • Phone numbers → +1-555-0100 (reserved)
  • Real names → Alice Smith, Bob Jones
  • Physical addresses → 123 Main St, Anytown, ST 12345
  • Company names → Acme Corp, Example Inc
  • Credit card numbers → 4111-1111-1111-1111 (test card)
  • Social security numbers → XXX-XX-XXXX
  • Passport numbers → XXXXXXXXX
  • Driver's license → DL-XXXXXXX
  • National IDs → Placeholder format

7. Cloud & Service Identifiers

Sanitize cloud-specific information:

  • AWS Account IDs → 123456789012 (example)
  • AWS Access Keys → AKIAIOSFODNN7EXAMPLE
  • GCP Project IDs → my-project-12345
  • Azure Subscription IDs → {subscription-id}
  • Docker image names with private registry → registry.example.com/image
  • S3 bucket names → my-bucket-example
  • CloudFront distributions → {distribution-id}

8. Version Control & Code

Sanitize VCS information:

  • Git remote URLs with credentials → Remove credentials
  • Git commit hashes (personal repos) → abc1234 (generic)
  • Branch names with usernames → feature/example-feature
  • Personal repository names → user/example-repo

Example:

Before: https://user:token@github.com/mycompany/private-repo.git
After:  https://github.com/example-org/example-repo.git

9. Dates & Timestamps with Context

Replace specific dates in examples:

  • Recent dates → 2026-01-15 (generic date)
  • Timestamps → 2026-01-01T00:00:00Z
  • Or use placeholders: {YYYY-MM-DD}, {timestamp}

10. URLs & Endpoints

Sanitize web resources:

  • Internal URLs → https://internal.example.com
  • API endpoints with auth → Remove tokens/keys
  • Webhook URLs with secrets → https://hooks.example.com/{id}
  • Admin panels → https://admin.example.com

11. License & Product Keys

NEVER include:

  • Software license keys
  • Product activation codes
  • Serial numbers
  • Registration codes

12. File Hashes & Checksums

Remove if contextual:

  • MD5/SHA hashes of personal files → Generic hash or {hash}
  • Keep only if demonstrating algorithm

13. Custom Internal Systems

Genericize:

  • Internal tool names → internal-tool, corp-system
  • Proprietary system identifiers
  • Custom protocol schemes
  • Internal service names

Sanitization Process

Step 1: Detect Modified Skill

After a skill file is created or modified, automatically:

  1. Identify the skill file path
  2. Read the complete content
  3. Scan for sensitive patterns

Step 2: Scan for Sensitive Information

Regular expressions to check:

# ===== FILE PATHS =====
# Windows paths with username
C:\\Users\\[^\\]+\\

# Unix paths with username  
/home/[^/]+/
/Users/[^/]+/

# Absolute paths
[A-Z]:\\[^`\
]+
/var/www/(?!example)[^/\s]+

# ===== NETWORK =====
# IP addresses (IPv4) - excluding reserved ranges
\b(?!(?:10\.|172\.(?:1[6-9]|2[0-9]|3[01])\.|192\.168\.|192\.0\.2\.|127\.))\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b

# IPv6 addresses
\b(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}\b

# MAC addresses
\b(?:[0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2}\b

# Private hostnames (not example.com/localhost)
\b(?!example\.com|localhost)[a-z0-9-]+\.(local|internal|corp|lan)\b

# ===== CREDENTIALS & SECRETS =====
# AWS Access Key IDs
\b(?:AKIA|ASIA)[0-9A-Z]{16}\b

# AWS Secret Keys
\b[A-Za-z0-9/+=]{40}\b

# Generic API keys
\b[aA][pP][iI][-_]?[kK][eE][yY]\s*[:=]\s*['\"]?[A-Za-z0-9_\-]{20,}

# Bearer tokens
[Bb]earer\s+[A-Za-z0-9\-._~+/]+=*

# Basic auth in URLs
https?://[^:]+:[^@]+@

# JWT tokens
eyJ[A-Za-z0-9_-]*\.eyJ[A-Za-z0-9_-]*\.[A-Za-z0-9_-]*

# Private keys
-----BEGIN\s+(?:RSA\s+)?PRIVATE\s+KEY-----

# ===== PERSONAL INFORMATION =====
# Real email addresses (not example.com)
\b[A-Za-z0-9._%+-]+@(?!example\.com|test\.com|demo\.com)[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b

# Phone numbers (various formats)
\+?1?[-.\s]?\(?[0-9]{3}\)?[-.\s]?[0-9]{3}[-.\s]?[0-9]{4}

# SSN format
\b\d{3}-\d{2}-\d{4}\b

# Credit card numbers
\b(?:\d{4}[-\s]?){3}\d{4}\b

# ===== USERNAMES & IDS =====
# Specific usernames in file patterns
\b([a-z]{5,}_(python|java|go|cpp))\b

# Employee IDs
\b(?:EMP|EMPLOYEE)[-_]?\d{4,}\b

# User IDs in paths
/users?/\d{5,}/

# ===== DATABASE =====
# Connection strings with credentials
(?:mongodb|mysql|postgresql|redis)://[^:]+:[^@]+@[^/\s]+

# Database hosts with specific names
\b(?:db|database|sql|mongo|redis)[-.](?!example)[a-z0-9-]+\.[a-z]{2,}\b

# ===== CLOUD & SERVICES =====
# AWS Account IDs (12 digits, not example)
\b(?!123456789012)\d{12}\b

# Docker private registries
\b(?!registry\.example\.com)[a-z0-9.-]+\.(?:azurecr\.io|gcr\.io|dkr\.ecr\.[a-z0-9-]+\.amazonaws\.com)

# S3 bucket names (specific ones)
s3://(?!example-bucket)[a-z0-9.-]{3,63}/

# ===== VERSION CONTROL =====
# Git URLs with credentials
git@(?!github\.com/example)[a-z0-9.-]+:[^/\s]+/[^\s]+\.git
https?://[^:]+:[^@]+@(?:github|gitlab|bitbucket)\.com

# Personal Git commit hashes in context
\bcommit\s+[0-9a-f]{7,40}\b

# ===== DATES WITH CONTEXT =====
# Recent specific dates (2024-2026 range)
202[4-6]-(?:0[4-9]|1[0-2])-(?:[0-2][0-9]|3[01])

# Timestamps with recent dates
202[4-6]-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}

# ===== OTHER =====
# File hashes (MD5, SHA1, SHA256) in personal context
\b[a-f0-9]{32}\b
\b[a-f0-9]{40}\b
\b[a-f0-9]{64}\b

# License keys (typical patterns)
\b[A-Z0-9]{5}-[A-Z0-9]{5}-[A-Z0-9]{5}-[A-Z0-9]{5}\b

# Internal tool/service names
\b(?:corp|internal|prod|staging)[-_][a-z0-9-]+\b

Step 3: Apply Replacements

Create a sanitized version with:

Path replacements:

C:\Users\*\.claude\             →  ~/.claude/
/home/*/.claude/                →  ~/.claude/
/Users/*/.claude/               →  ~/.claude/

Username replacements in examples:

john_python.md                  →  alice_python.md
mary_java.md                    →  bob_java.md
userspecificname                →  {username}

Date replacements in examples:

Recent specific dates            →  Generic dates (2026-01-15)

Step 4: Validate & Update

  1. Verify all sensitive patterns are removed
  2. Ensure skill functionality is preserved
  3. Write sanitized content back to skill file
  4. Report what was sanitized

Security Checklist

Before finalizing any skill, verify:

✓ Credentials & Secrets

  • [ ] No API keys, tokens, passwords
  • [ ] No private keys or certificates
  • [ ] No session tokens or cookies
  • [ ] No authentication credentials

✓ Network Information

  • [ ] No real IP addresses (use TEST-NET or generic)
  • [ ] No MAC addresses
  • [ ] No internal hostnames
  • [ ] No specific port configurations with context

✓ Personal Information

  • [ ] No real email addresses (use example.com)
  • [ ] No phone numbers (use +1-555-0100)
  • [ ] No real names (use Alice, Bob)
  • [ ] No physical addresses
  • [ ] No government IDs (SSN, passport, etc.)

✓ Infrastructure

  • [ ] No real database connection strings
  • [ ] No specific cloud account IDs
  • [ ] No private registry URLs
  • [ ] No internal service names

✓ Identifiers

  • [ ] No real usernames (use placeholders)
  • [ ] No employee IDs
  • [ ] No specific project names
  • [ ] No proprietary system names

✓ File Paths

  • [ ] All paths use ~/ notation
  • [ ] No absolute paths with usernames
  • [ ] No drive letters (C:\, D:\)

Output Format

After sanitization, output:

🔒 Skill Sanitized: {skill_name}

Security scan completed:
  ✓ {N} absolute path(s) → replaced with ~/
  ✓ {N} username(s) → replaced with generic names
  ✓ {N} IP address(es) → replaced with TEST-NET
  ✓ {N} email(s) → replaced with example.com
  ✓ {N} credential(s) → REMOVED
  ✓ {N} date(s) → replaced with generic dates
  ✓ {N} hostname(s) → replaced with example.com
  ✓ {N} connection string(s) → replaced with placeholder
  ✓ {N} other sensitive item(s) → removed/replaced

🛡️  Skill is now secure, generic, and shareable.

If no sensitive info found:

✓ Skill already secure: {skill_name}
  No sensitive information detected.

If CRITICAL issues found (credentials, keys):

🚨 CRITICAL: Blocked sensitive data in {skill_name}

REMOVED:
  ⚠️  {N} API key(s)
  ⚠️  {N} password(s)
  ⚠️  {N} private key(s)
  ⚠️  {N} token(s)

These items were completely removed (not replaced).
Manual review recommended.

Important Rules

Priority Rules

  1. SECURITY FIRST - When in doubt, remove or genericize
  2. Zero tolerance for credentials - Never allow API keys, passwords, tokens
  3. Err on the side of caution - Better to over-sanitize than leak data
  4. Block, don't log - Never log sensitive data during sanitization process

Functional Rules

  1. Never break functionality - Only replace examples/paths, not actual logic
  2. Preserve placeholders - Keep existing {username}, {domain} intact
  3. Use generic examples - alice, bob, user for examples
  4. Cross-platform paths - Always use ~/ notation
  5. No false positives - Don't replace technical terms unless clearly identifiable

Replacement Standards

  1. Consistent replacements - Same input → same output across all skills
  2. Use standard test data - TEST-NET IPs, +1-555-0100 phones, example.com domains
  3. Document replacements - Track what was changed in output
  4. Verify after replacement - Ensure skill still makes sense

Red Flags - ALWAYS investigate

  • Anything that looks like a key or token
  • Long alphanumeric strings (40+ chars)
  • Strings with "key", "secret", "token", "password" nearby
  • Connection strings with @ symbol
  • URLs with authentication
  • Base64-encoded strings in sensitive contexts
  • Hex strings (MD5, SHA hashes)
  • JSON with "password", "token", "secret" fields

Edge Cases & Special Handling

DON'T Sanitize (False Positives to Avoid)

  • Code variable names - username, password as variable names in code examples
  • Placeholder syntax - {username}, {domain}, {api-key} already in placeholder format
  • Technical terms - python, java, nodejs as technology names
  • Generic examples - alice, bob, user already used as generic names
  • Reserved ranges - 192.0.2.x, 10.0.0.x already in use as examples
  • Example domains - example.com, test.com, localhost
  • Test phone numbers - +1-555-0100 series (already reserved)
  • Documentation IDs - user-id-123, session-abc in placeholder format
  • Algorithm examples - Hash outputs when demonstrating algorithms
  • Public APIs - Public API endpoints that are meant to be public

DO Sanitize (True Positives)

  • Actual credentials - Even if commented out or in example sections
  • Real paths - Even in comments or documentation
  • Personal identifiers - Names, emails, IDs specific to individuals
  • Internal systems - Private hostnames, internal IPs, proprietary names
  • Recent timestamps - Dates/times that correlate to real events
  • Organization data - Real company names, project names, team names
  • Cloud resources - Actual account IDs, bucket names, instance IDs
  • Version control - Real repository URLs, commit hashes from private repos

Special Cases

Localhost & Local Development:

  • Keep: localhost, 127.0.0.1, 0.0.0.0
  • Sanitize: Specific local network IPs like 192.168.1.100

Ports:

  • Keep: Standard ports (80, 443, 3000, 8080) without context
  • Sanitize: Unusual ports that might identify specific services

Documentation URLs:

  • Keep: Official documentation links (docs.python.org, github.com/project/repo)
  • Sanitize: Links to internal wikis, private repos, company intranets

Code Examples:

  • Keep: Demonstrative code that shows structure
  • Sanitize: Real code snippets from actual projects

Error Messages:

  • Keep: Generic error formats
  • Sanitize: Error messages with real paths, usernames, or system info

Log Samples:

  • Keep: Sanitized log format examples
  • Sanitize: Real log entries with timestamps, IPs, or usernames

Manual Invocation

User can explicitly trigger with:

  • "sanitize this skill"
  • "remove sensitive info from {skill_name}"
  • "clean up the skill"

Then follow the same process above.

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

96.94%
按下载量换算695

安全审计

VirusTotal

通过

ClawScan

可疑

Static analysis

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills