RuView PII Detector Agent构建多智能体安全体系中的敏感信息与凭据泄漏扫描器【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView本文以 RuView 仓库中的智能体定义文件 .claude/agents/v3/pii-detector.md 为主体完整讲解这个专用 PII个人身份信息检测 Agent 的检测目标、正则扫描模式、修复建议与 Swarm 上报机制并结合仓库中 security-scanner.sh、redact-secrets.py 等配套实现说明该 Agent 如何落地到一条可验证的数据合规防线。读完本篇你可以掌握一个「检测目标定义 → 正则模式库 → 修复建议 → 合规上下文 → 蜂群集成」的完整安全 Agent 设计范式并能在自己的仓库中复刻同类扫描能力。PII Detector Agent 的定位与声明式配置RuView 采用 claude-flow 多智能体Swarm工作流组织开发过程安全类 Agent 集中在 .claude/agents/v3/ 目录下。其中的pii-detector是一个专职的敏感信息扫描器它的职责不是查漏洞而是识别代码、数据文件和 Agent 通信中泄漏的个人敏感信息与凭据并在命中时给出分类与修复建议。该 Agent 采用 YAML frontmatter Markdown 正文的声明式定义frontmatter 中的每一项字段都有明确的运行时含义字段取值含义namepii-detectorAgent 唯一标识typesecurity安全类 Agent与同目录的aidefence-guardian、security-auditor等同属安全域color#FF5722Swarm 可视化中的显示色description扫描代码与数据中的敏感信息泄漏Agent 职责的一句话摘要capabilitiespii_detection/credential_scanning/secret_detection/data_classification/compliance_checking能力标签供编排器按能力路由任务priorityhigh调度优先级requires.packagesclaude-flow/aidefence声明式依赖的检测库hooks.pre/hooks.post扫描开始/结束提示生命周期钩子扫描前后输出状态日志从源码结构看requires.packages声明了该 Agent 的能力依托外部 npm 包claude-flow/aidefence提供该包在 Agent 文件中以createAIDefence()工厂函数暴露 APIcapabilities与priority则服务于 Swarm 编排器——编排器可以基于能力标签把扫描某目录的敏感数据这一类任务分派给本 Agent。hooks中的pre/post是 shell 片段分别用于标记一次扫描会话的开始与结束保证扫描过程在会话日志中可追踪。三大检测目标类别Agent 文档将检测目标划分为三个正交类别这个划分直接决定了后续正则库与合规映射的组织方式1. 个人身份信息PII邮箱地址Email addresses社会安全号SSN电话号码Phone numbers物理地址Physical addresses特定上下文中的姓名Names in specific contexts2. 凭据与密钥Credentials SecretsAPI 密钥OpenAI、Anthropic、GitHub、AWS 等密码硬编码在代码中或写在配置文件里数据库连接字符串私有密钥与证书Private keys and certificatesOAuth token 与 refresh token3. 金融数据Financial Data信用卡号银行账户号各类金融标识符这个分类的意义在于修复策略与合规映射都按类别分派。API Key 泄漏走环境化/密钥管理器路线PII 走脱敏/tokenization路线金融数据则直接触发 PCI-DSS 级别的处置。检测 API 与调用示例Agent 文档给出的标准用法基于claude-flow/aidefence的createAIDefence()工厂核心调用链是detector.detect(content)→ 检查result.piiFound→ 对命中类型做逐行统计与行号定位import { createAIDefence } from claude-flow/aidefence; const detector createAIDefence(); async function scanForPII(content: string, source: string) { const result await detector.detect(content); if (result.piiFound) { console.log(⚠️ PII detected in ${source}); // Detailed PII analysis const piiTypes analyzePIITypes(content); for (const pii of piiTypes) { console.log( - ${pii.type}: ${pii.count} instance(s)); if (pii.locations) { console.log( Lines: ${pii.locations.join(, )}); } } return { hasPII: true, types: piiTypes }; } return { hasPII: false, types: [] }; } // Scan a file const fileContent await readFile(config.json); const result await scanForPII(fileContent, config.json); if (result.hasPII) { console.log( Action required: Remove or encrypt sensitive data); }从这段接口契约可以提炼出三点设计要点检测与分类解耦detect()只负责判定是否命中piiFound布尔位具体类型统计由analyzePIITypes()完成返回{ type, count, locations }三元组——这意味着扫描结果天然可结构化为报告字段定位到行locations是行号数组这是安全扫描工具的关键能力——只报有泄漏不够必须能指到具体行才能修复动作出口明确命中后统一输出 Action required: Remove or encrypt sensitive data把处置语义交给上层Swarm 编排器或人决策而不是扫描器自行修改文件。正则扫描模式库Agent 文档内置了两组可直接复用的正则模式库这是整份文档最具实战价值的部分。API Key 模式const API_KEY_PATTERNS [ // OpenAI /sk-[a-zA-Z0-9]{48}/g, // Anthropic /sk-ant-api[a-zA-Z0-9-]{90,}/g, // GitHub /ghp_[a-zA-Z0-9]{36}/g, /github_pat_[a-zA-Z0-9_]{82}/g, // AWS /AKIA[0-9A-Z]{16}/g, // Generic /api[_-]?key\s*[:]\s*[][^][]/gi, ];逐条解读各模式的匹配语义与适用前提模式厂商/用途语义sk-[a-zA-Z0-9]{48}OpenAIsk-前缀 恰好 48 位字母数字匹配经典 API key 形态sk-ant-api[a-zA-Z0-9-]{90,}Anthropicsk-ant-api前缀 至少 90 位字母数字连字符前缀本身已强约束长度用下界兜底ghp_[a-zA-Z0-9]{36}GitHub PATghp_前缀 恰好 36 位即 classic personal access tokengithub_pat_[a-zA-Z0-9_]{82}GitHub 细粒度 tokengithub_pat_前缀 恰好 82 位即 fine-grained PATAKIA[0-9A-Z]{16}AWS Access Key IDAKIA前缀 恰好 16 位大写字母数字这是 AWS access key 的公开形态api[_-]?key\s*[:]\s*[][^][]通用键名启发式api_key/apikey/api-key后跟赋值与引号包裹的任意值作为厂商模式未命中时的兜底值得注意的是两条设计取舍厂商模式依赖前缀 精确长度误报率极低但只能覆盖已知厂商通用模式依赖键名启发式覆盖面广但依赖配置书写习惯key、token等变体需要自行扩展。i标志让键名匹配大小写不敏感而厂商 token 模式保持大小写敏感——因为真实 token 的字母大小写是形态的一部分。密码模式const PASSWORD_PATTERNS [ /password\s*[:]\s*[][^][]/gi, /passwd\s*[:]\s*[][^][]/gi, /secret\s*[:]\s*[][^][]/gi, /credentials\s*[:]\s*\{[^}]\}/gi, ];这四条全部是键名启发式匹配password、passwd、secret三个字面键以及credentials对象字面量覆盖 JSON/TOML/配置文件中最常见的明文凭据赋值形态。credentials一条用\{[^}]\}匹配花括号对象而非引号串说明它假设凭据常以对象形式如{ username: ..., password: ... }出现。这套键名启发式与仓库中另一套 bash 级扫描器形成了互证。.claude/helpers/security-scanner.sh 的scan_secrets()函数使用同样的思路但面向 shell 环境用grep -riE实现local patterns( password\s*\s*[\][^\][\] api[_-]?key\s*\s*[\][^\][\] secret\s*\s*[\][^\][\] token\s*\s*[\][^\][\] private[_-]?key )对照两套模式库可以看到清晰的工程分层Agent 文档中的 TypeScript 正则库用于精确的逐行报告带行号、类型、计数而 bash 扫描器用于低成本的仓库级统计——它只累加命中行数并输出secrets总量配合 30 分钟节流should_run()中1800秒阈值与clean/warning/critical三档状态机10判 critical、0判 warning结果写入.claude-flow/security/scan-results.json。两者共用同一组键名启发式心智模型只是运行在不同工具层。修复建议Remediation检测到命中后Agent 按数据类别给出四条修复路线——这是检测 → 处置闭环中处置端的规范API Keys改用环境变量或密钥管理器secret managers把明文值移出源码树Passwords放入.env文件并确保其被 gitignore或接入 vault 方案代码中的 PII实施数据脱敏masking或 tokenization日志在写日志之前启用 PII scrubbing避免凭据/个人数据经由日志二次扩散。这四条建议在 RuView 仓库中都能找到对应的落地实现说明它们不是纸面规范日志脱敏对应 scripts/redact-secrets.py。它是 generate-witness-bundle.sh 在生成见证包witness bundle前串联在命令输出管道中的过滤层verify.py 21 | python3 scripts/redact-secrets.py用纯标准库正则把 SaaS token 前缀sk-、ghp_、AKIA、hf_、xoxb-等、40 位不透明长串、20 位 hex 串以及token|password|secret|api_key...形式的赋值统一替换为[REDACTED]。这与 PII Detector 文档第 4 条日志写入前 scrubbing是同一条原则的具体实现仓库级数据拦截对应 scripts/csi-data-policy-check.sh见下节。与 Security Swarm 的集成命中结果的结构化上报PII Detector 不是孤立运行的——它作为 Swarm 中的一员把发现写入共享记忆命名空间供其他 Agent如 Guardian、Auditor查询与联动。文档给出的上报协议如下// Report PII findings to swarm mcp__claude-flow__memory_usage({ action: store, namespace: pii_findings, key: pii-${Date.now()}, value: JSON.stringify({ agent: pii-detector, source: fileName, piiTypes: detectedTypes, severity: calculateSeverity(detectedTypes), timestamp: Date.now() }) });这个上报结构值得注意的三个字段namespace: pii_findings按发现类型隔离命名空间Swarm 其他成员只查自己关心的类别避免安全事件流混杂severity: calculateSeverity(detectedTypes)严重度由命中的 PII 类型推导而非固定值——意味着 SSN 或私钥的严重度必然高于一个普通邮箱这正是合规映射下节在数据层的体现key: pii-${Date.now()}以时间戳做键天然保证并发扫描时多条发现不互相覆盖。合规上下文Compliance Context文档把检测能力映射到四个合规框架明确了每个框架下本 Agent 回答的问题框架对应检测目标GDPR个人数据识别邮箱、SSN、电话、地址等 PII 类别HIPAA受保护健康信息PHI——对 RuView 这类做呼吸/心率等生命体征监测的项目尤其相关PCI-DSS支付卡数据信用卡号、银行账户号SOC 2敏感数据处理实践凭据、密钥、日志脱敏文档的收尾原则是Always recommend appropriate data handling based on detected PII type and applicable compliance requirements——即处置建议必须按PII 类型 × 适用合规要求二维查表给出而不是对一切命中一刀切。仓库纵深佐证当个人数据指 WiFi 信号本身上述集成与合规章节若只看 Agent 文档读者可能疑惑一个 WiFi 感知项目为什么要配 PII 检测docs/adr/ADR-299-csi-data-incident-repo-controls.md 给出了答案原始 CSI 信道数据本身就是个人数据——它编码了人的呼吸、动作与在场信息等价于行为生物特征。该 ADR 记录了一次真实数据事故约 64.6 MB 原始 CSI 录音因.gitignore规则失效被提交进仓库并落了两道机械化防线.gitignore覆盖data/recordings/、v2/data/recordings/与*.csi.jsonl/*.csi.meta.json通配csi-data-policy-check.sh确定性、离线、可 pre-commit/CI 双跑的守卫脚本。它的行为契约与 PII Detector 的检测 → 定位 → 建议完全同构classify()按扩展名分类命中*.csi.jsonl一律拦截*.jsonl仅在超过CSI_POLICY_MAX_JSONL_BYTES默认 5 MB时拦截scan_stdin()输出带文件路径的BLOCK:行定位能力退出码 0/1/2 区分 clean/违规/环境错误可供 CI 门禁消费合成测试 fixture 可通过 scripts/csi-data-policy.allow 白名单豁免对应 PII Detector 修复建议中的tokenization/脱敏后测试原则脚本内置--self-test用确定性 fixture 断言拦截 csi 流、放行小 jsonl、放行白名单六条断言全部通过与 ADR 的 Validation 章节逐条对应。这套脚本证明 PII Detector 文档中数据分类data_classification能力在 RuView 中并非抽象声明分类对象从代码里的 API key扩展到了仓库里的人体传感数据文件检测、白名单、基线豁免CSI_POLICY_BASELINE与 CI 门禁形成完整闭环。同域协作与 AIDefence Guardian 的分工在 .claude/agents/v3/ 安全 Agent 家族中pii-detector与 aidefence-guardian.md 构成互补分工两者依赖同一个claude-flow/aidefence包pii-detector面向静态资产扫代码、配置文件、数据文件与 Agent 通信内容中的敏感信息输出类型 行号 计数的明细报告优先级highaidefence-guardian面向动态通信拦截式监控所有 Agent 输入/输出把 PII 暴露列为六种威胁类型之一pii_exposure——文档原文明确列出 Emails, SSNs, API keys, passwords并叠加提示注入、越狱、编码攻击等检测拥有critical优先级与会话级统计scans/blocked/warned。可以推断这条设计意图是Guardian 在输入侧做实时拦截发现pii_exposure即告警/阻断PII Detector 在资产侧做周期性深扫与合规报告两者通过共享记忆命名空间pii_findings/security_detections交换发现构成拦截层 审计层的双层防御。小结可复刻的敏感信息扫描设计清单把 .claude/agents/v3/pii-detector.md 的设计要素与仓库配套实现对照可以得到一份可移植到其他项目的清单声明式 Agent 定义frontmatter 声明capabilities、priority、requires.packages与生命周期hooks正文给出职责与操作规范——pii-detector.md三层检测目标分类PII / 凭据密钥 / 金融数据分类决定修复策略与合规映射双模正则库厂商前缀 精确长度低误报与键名启发式广覆盖组合——API_KEY_PATTERNS、PASSWORD_PATTERNSbash 层的 security-scanner.sh 是其低成本孪生实现四条修复路线环境变量/密钥管理器、.env vault、masking/tokenization、日志前 scrubbing——分别由 redact-secrets.py 等仓库脚本兑现结构化上报pii_findings命名空间 时间戳键 类型推导严重度让 Swarm 其他成员可查询、可联动合规映射GDPR/HIPAA/PCI-DSS/SOC 2 四框架按 PII 类型查表给出处置建议仓库级数据守卫以 csi-data-policy-check.sh ADR-299 为范本把个人数据不可入库做成确定性、离线、带自测试的 CI 门禁。整套方案的共同特点是机械可验证正则可单测、守卫脚本离线确定、命中报告带行号与严重度、合规映射有文档依据——这使得 PII 检测从Agent 的一次提示词指令升级为仓库里可复跑、可审计的工程实践。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RuView PII Detector Agent：构建多智能体安全体系中的敏感信息与凭据泄漏扫描器
RuView PII Detector Agent构建多智能体安全体系中的敏感信息与凭据泄漏扫描器【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView本文以 RuView 仓库中的智能体定义文件 .claude/agents/v3/pii-detector.md 为主体完整讲解这个专用 PII个人身份信息检测 Agent 的检测目标、正则扫描模式、修复建议与 Swarm 上报机制并结合仓库中 security-scanner.sh、redact-secrets.py 等配套实现说明该 Agent 如何落地到一条可验证的数据合规防线。读完本篇你可以掌握一个「检测目标定义 → 正则模式库 → 修复建议 → 合规上下文 → 蜂群集成」的完整安全 Agent 设计范式并能在自己的仓库中复刻同类扫描能力。PII Detector Agent 的定位与声明式配置RuView 采用 claude-flow 多智能体Swarm工作流组织开发过程安全类 Agent 集中在 .claude/agents/v3/ 目录下。其中的pii-detector是一个专职的敏感信息扫描器它的职责不是查漏洞而是识别代码、数据文件和 Agent 通信中泄漏的个人敏感信息与凭据并在命中时给出分类与修复建议。该 Agent 采用 YAML frontmatter Markdown 正文的声明式定义frontmatter 中的每一项字段都有明确的运行时含义字段取值含义namepii-detectorAgent 唯一标识typesecurity安全类 Agent与同目录的aidefence-guardian、security-auditor等同属安全域color#FF5722Swarm 可视化中的显示色description扫描代码与数据中的敏感信息泄漏Agent 职责的一句话摘要capabilitiespii_detection/credential_scanning/secret_detection/data_classification/compliance_checking能力标签供编排器按能力路由任务priorityhigh调度优先级requires.packagesclaude-flow/aidefence声明式依赖的检测库hooks.pre/hooks.post扫描开始/结束提示生命周期钩子扫描前后输出状态日志从源码结构看requires.packages声明了该 Agent 的能力依托外部 npm 包claude-flow/aidefence提供该包在 Agent 文件中以createAIDefence()工厂函数暴露 APIcapabilities与priority则服务于 Swarm 编排器——编排器可以基于能力标签把扫描某目录的敏感数据这一类任务分派给本 Agent。hooks中的pre/post是 shell 片段分别用于标记一次扫描会话的开始与结束保证扫描过程在会话日志中可追踪。三大检测目标类别Agent 文档将检测目标划分为三个正交类别这个划分直接决定了后续正则库与合规映射的组织方式1. 个人身份信息PII邮箱地址Email addresses社会安全号SSN电话号码Phone numbers物理地址Physical addresses特定上下文中的姓名Names in specific contexts2. 凭据与密钥Credentials SecretsAPI 密钥OpenAI、Anthropic、GitHub、AWS 等密码硬编码在代码中或写在配置文件里数据库连接字符串私有密钥与证书Private keys and certificatesOAuth token 与 refresh token3. 金融数据Financial Data信用卡号银行账户号各类金融标识符这个分类的意义在于修复策略与合规映射都按类别分派。API Key 泄漏走环境化/密钥管理器路线PII 走脱敏/tokenization路线金融数据则直接触发 PCI-DSS 级别的处置。检测 API 与调用示例Agent 文档给出的标准用法基于claude-flow/aidefence的createAIDefence()工厂核心调用链是detector.detect(content)→ 检查result.piiFound→ 对命中类型做逐行统计与行号定位import { createAIDefence } from claude-flow/aidefence; const detector createAIDefence(); async function scanForPII(content: string, source: string) { const result await detector.detect(content); if (result.piiFound) { console.log(⚠️ PII detected in ${source}); // Detailed PII analysis const piiTypes analyzePIITypes(content); for (const pii of piiTypes) { console.log( - ${pii.type}: ${pii.count} instance(s)); if (pii.locations) { console.log( Lines: ${pii.locations.join(, )}); } } return { hasPII: true, types: piiTypes }; } return { hasPII: false, types: [] }; } // Scan a file const fileContent await readFile(config.json); const result await scanForPII(fileContent, config.json); if (result.hasPII) { console.log( Action required: Remove or encrypt sensitive data); }从这段接口契约可以提炼出三点设计要点检测与分类解耦detect()只负责判定是否命中piiFound布尔位具体类型统计由analyzePIITypes()完成返回{ type, count, locations }三元组——这意味着扫描结果天然可结构化为报告字段定位到行locations是行号数组这是安全扫描工具的关键能力——只报有泄漏不够必须能指到具体行才能修复动作出口明确命中后统一输出 Action required: Remove or encrypt sensitive data把处置语义交给上层Swarm 编排器或人决策而不是扫描器自行修改文件。正则扫描模式库Agent 文档内置了两组可直接复用的正则模式库这是整份文档最具实战价值的部分。API Key 模式const API_KEY_PATTERNS [ // OpenAI /sk-[a-zA-Z0-9]{48}/g, // Anthropic /sk-ant-api[a-zA-Z0-9-]{90,}/g, // GitHub /ghp_[a-zA-Z0-9]{36}/g, /github_pat_[a-zA-Z0-9_]{82}/g, // AWS /AKIA[0-9A-Z]{16}/g, // Generic /api[_-]?key\s*[:]\s*[][^][]/gi, ];逐条解读各模式的匹配语义与适用前提模式厂商/用途语义sk-[a-zA-Z0-9]{48}OpenAIsk-前缀 恰好 48 位字母数字匹配经典 API key 形态sk-ant-api[a-zA-Z0-9-]{90,}Anthropicsk-ant-api前缀 至少 90 位字母数字连字符前缀本身已强约束长度用下界兜底ghp_[a-zA-Z0-9]{36}GitHub PATghp_前缀 恰好 36 位即 classic personal access tokengithub_pat_[a-zA-Z0-9_]{82}GitHub 细粒度 tokengithub_pat_前缀 恰好 82 位即 fine-grained PATAKIA[0-9A-Z]{16}AWS Access Key IDAKIA前缀 恰好 16 位大写字母数字这是 AWS access key 的公开形态api[_-]?key\s*[:]\s*[][^][]通用键名启发式api_key/apikey/api-key后跟赋值与引号包裹的任意值作为厂商模式未命中时的兜底值得注意的是两条设计取舍厂商模式依赖前缀 精确长度误报率极低但只能覆盖已知厂商通用模式依赖键名启发式覆盖面广但依赖配置书写习惯key、token等变体需要自行扩展。i标志让键名匹配大小写不敏感而厂商 token 模式保持大小写敏感——因为真实 token 的字母大小写是形态的一部分。密码模式const PASSWORD_PATTERNS [ /password\s*[:]\s*[][^][]/gi, /passwd\s*[:]\s*[][^][]/gi, /secret\s*[:]\s*[][^][]/gi, /credentials\s*[:]\s*\{[^}]\}/gi, ];这四条全部是键名启发式匹配password、passwd、secret三个字面键以及credentials对象字面量覆盖 JSON/TOML/配置文件中最常见的明文凭据赋值形态。credentials一条用\{[^}]\}匹配花括号对象而非引号串说明它假设凭据常以对象形式如{ username: ..., password: ... }出现。这套键名启发式与仓库中另一套 bash 级扫描器形成了互证。.claude/helpers/security-scanner.sh 的scan_secrets()函数使用同样的思路但面向 shell 环境用grep -riE实现local patterns( password\s*\s*[\][^\][\] api[_-]?key\s*\s*[\][^\][\] secret\s*\s*[\][^\][\] token\s*\s*[\][^\][\] private[_-]?key )对照两套模式库可以看到清晰的工程分层Agent 文档中的 TypeScript 正则库用于精确的逐行报告带行号、类型、计数而 bash 扫描器用于低成本的仓库级统计——它只累加命中行数并输出secrets总量配合 30 分钟节流should_run()中1800秒阈值与clean/warning/critical三档状态机10判 critical、0判 warning结果写入.claude-flow/security/scan-results.json。两者共用同一组键名启发式心智模型只是运行在不同工具层。修复建议Remediation检测到命中后Agent 按数据类别给出四条修复路线——这是检测 → 处置闭环中处置端的规范API Keys改用环境变量或密钥管理器secret managers把明文值移出源码树Passwords放入.env文件并确保其被 gitignore或接入 vault 方案代码中的 PII实施数据脱敏masking或 tokenization日志在写日志之前启用 PII scrubbing避免凭据/个人数据经由日志二次扩散。这四条建议在 RuView 仓库中都能找到对应的落地实现说明它们不是纸面规范日志脱敏对应 scripts/redact-secrets.py。它是 generate-witness-bundle.sh 在生成见证包witness bundle前串联在命令输出管道中的过滤层verify.py 21 | python3 scripts/redact-secrets.py用纯标准库正则把 SaaS token 前缀sk-、ghp_、AKIA、hf_、xoxb-等、40 位不透明长串、20 位 hex 串以及token|password|secret|api_key...形式的赋值统一替换为[REDACTED]。这与 PII Detector 文档第 4 条日志写入前 scrubbing是同一条原则的具体实现仓库级数据拦截对应 scripts/csi-data-policy-check.sh见下节。与 Security Swarm 的集成命中结果的结构化上报PII Detector 不是孤立运行的——它作为 Swarm 中的一员把发现写入共享记忆命名空间供其他 Agent如 Guardian、Auditor查询与联动。文档给出的上报协议如下// Report PII findings to swarm mcp__claude-flow__memory_usage({ action: store, namespace: pii_findings, key: pii-${Date.now()}, value: JSON.stringify({ agent: pii-detector, source: fileName, piiTypes: detectedTypes, severity: calculateSeverity(detectedTypes), timestamp: Date.now() }) });这个上报结构值得注意的三个字段namespace: pii_findings按发现类型隔离命名空间Swarm 其他成员只查自己关心的类别避免安全事件流混杂severity: calculateSeverity(detectedTypes)严重度由命中的 PII 类型推导而非固定值——意味着 SSN 或私钥的严重度必然高于一个普通邮箱这正是合规映射下节在数据层的体现key: pii-${Date.now()}以时间戳做键天然保证并发扫描时多条发现不互相覆盖。合规上下文Compliance Context文档把检测能力映射到四个合规框架明确了每个框架下本 Agent 回答的问题框架对应检测目标GDPR个人数据识别邮箱、SSN、电话、地址等 PII 类别HIPAA受保护健康信息PHI——对 RuView 这类做呼吸/心率等生命体征监测的项目尤其相关PCI-DSS支付卡数据信用卡号、银行账户号SOC 2敏感数据处理实践凭据、密钥、日志脱敏文档的收尾原则是Always recommend appropriate data handling based on detected PII type and applicable compliance requirements——即处置建议必须按PII 类型 × 适用合规要求二维查表给出而不是对一切命中一刀切。仓库纵深佐证当个人数据指 WiFi 信号本身上述集成与合规章节若只看 Agent 文档读者可能疑惑一个 WiFi 感知项目为什么要配 PII 检测docs/adr/ADR-299-csi-data-incident-repo-controls.md 给出了答案原始 CSI 信道数据本身就是个人数据——它编码了人的呼吸、动作与在场信息等价于行为生物特征。该 ADR 记录了一次真实数据事故约 64.6 MB 原始 CSI 录音因.gitignore规则失效被提交进仓库并落了两道机械化防线.gitignore覆盖data/recordings/、v2/data/recordings/与*.csi.jsonl/*.csi.meta.json通配csi-data-policy-check.sh确定性、离线、可 pre-commit/CI 双跑的守卫脚本。它的行为契约与 PII Detector 的检测 → 定位 → 建议完全同构classify()按扩展名分类命中*.csi.jsonl一律拦截*.jsonl仅在超过CSI_POLICY_MAX_JSONL_BYTES默认 5 MB时拦截scan_stdin()输出带文件路径的BLOCK:行定位能力退出码 0/1/2 区分 clean/违规/环境错误可供 CI 门禁消费合成测试 fixture 可通过 scripts/csi-data-policy.allow 白名单豁免对应 PII Detector 修复建议中的tokenization/脱敏后测试原则脚本内置--self-test用确定性 fixture 断言拦截 csi 流、放行小 jsonl、放行白名单六条断言全部通过与 ADR 的 Validation 章节逐条对应。这套脚本证明 PII Detector 文档中数据分类data_classification能力在 RuView 中并非抽象声明分类对象从代码里的 API key扩展到了仓库里的人体传感数据文件检测、白名单、基线豁免CSI_POLICY_BASELINE与 CI 门禁形成完整闭环。同域协作与 AIDefence Guardian 的分工在 .claude/agents/v3/ 安全 Agent 家族中pii-detector与 aidefence-guardian.md 构成互补分工两者依赖同一个claude-flow/aidefence包pii-detector面向静态资产扫代码、配置文件、数据文件与 Agent 通信内容中的敏感信息输出类型 行号 计数的明细报告优先级highaidefence-guardian面向动态通信拦截式监控所有 Agent 输入/输出把 PII 暴露列为六种威胁类型之一pii_exposure——文档原文明确列出 Emails, SSNs, API keys, passwords并叠加提示注入、越狱、编码攻击等检测拥有critical优先级与会话级统计scans/blocked/warned。可以推断这条设计意图是Guardian 在输入侧做实时拦截发现pii_exposure即告警/阻断PII Detector 在资产侧做周期性深扫与合规报告两者通过共享记忆命名空间pii_findings/security_detections交换发现构成拦截层 审计层的双层防御。小结可复刻的敏感信息扫描设计清单把 .claude/agents/v3/pii-detector.md 的设计要素与仓库配套实现对照可以得到一份可移植到其他项目的清单声明式 Agent 定义frontmatter 声明capabilities、priority、requires.packages与生命周期hooks正文给出职责与操作规范——pii-detector.md三层检测目标分类PII / 凭据密钥 / 金融数据分类决定修复策略与合规映射双模正则库厂商前缀 精确长度低误报与键名启发式广覆盖组合——API_KEY_PATTERNS、PASSWORD_PATTERNSbash 层的 security-scanner.sh 是其低成本孪生实现四条修复路线环境变量/密钥管理器、.env vault、masking/tokenization、日志前 scrubbing——分别由 redact-secrets.py 等仓库脚本兑现结构化上报pii_findings命名空间 时间戳键 类型推导严重度让 Swarm 其他成员可查询、可联动合规映射GDPR/HIPAA/PCI-DSS/SOC 2 四框架按 PII 类型查表给出处置建议仓库级数据守卫以 csi-data-policy-check.sh ADR-299 为范本把个人数据不可入库做成确定性、离线、带自测试的 CI 门禁。整套方案的共同特点是机械可验证正则可单测、守卫脚本离线确定、命中报告带行号与严重度、合规映射有文档依据——这使得 PII 检测从Agent 的一次提示词指令升级为仓库里可复跑、可审计的工程实践。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考