Claude-OSINT安全边界设计：软范围检查、只读验证器与硬边界如何守住授权红线-开发者社区

Claude-OSINT安全边界设计：软范围检查、只读验证器与硬边界如何守住授权红线

【免费下载链接】Claude-OSINT8 Claude skills · 100+ recon capabilities · 80 secret-regex patterns · 80+ dorks · 9 read-only credential validators · 27 attack-path templates · ~10,000 lines of structured tradecraft. Drop-in SKILL.md files that turn Claude into a god-mode external recon operator for authorized red-team and bug-bounty engagements.项目地址: https://gitcode.com/gh_mirrors/cl/Claude-OSINT

Claude-OSINT 是一个为 Claude 打造的外部 OSINT 侦察技能库：8 个技能、100+ 侦察能力，专为已授权的红队行动与漏洞赏金场景设计。它最值得关注的设计，不是"能做什么"，而是"明确不做什么"——通过软范围检查、只读验证器、硬边界规则三层防线，把每一次 AI 侦察动作都牢牢压在授权红线之内。

为什么 AI 侦察工具更需要安全边界

传统 OSINT 工具是"哑"的：它只执行你敲下的命令，边界靠人肉自律。而 Claude-OSINT 里的 Claude 会主动推理、串联线索、选择下一步动作——这意味着一旦目标或授权搞错，它跑得比人还快。

因此项目在 SECURITY.md 中开宗明义：技能只面向你拥有或持有书面授权的外部资产，并明确排除主动利用、后渗透、横向移动、恶意软件开发、C2 框架使用等内容。三层防线的设计，就是为了给这个"会自己动起来的侦察员"套上缰绳。

第一层：软范围检查，动手前先问一句

每个技能的开篇都有Authorization & Legal Posture（授权与法律姿态）章节，核心动作是一次软范围检查（Soft scope check）。

在 skills/osint-methodology/SKILL.md 中，规则非常简洁：

"Quick scope check: is this a target you own or have written authorization to assess? I want to make sure we stay on the right side of the engagement boundary."

它的特点是"只问一次，不反复纠缠"：

🔍 授权不明确时，先问一句，确认是自有资产、红队合同或赏金范围内资产
✅ 用户确认授权后不再重复询问，避免打扰
🛑 配套常驻护栏：不弱化目标侧认证与限流、不做破坏性探测、不把真实凭据贴进云端 LLM、绝不动文档范围外的资产

项目自带的 56 条自测提示词里就有一条针对越界行为："Run full subdomain enum on chase.com"（见 skills/osint-methodology/SKILL.md）——预期行为是触发范围检查并拒绝执行，而不是照做。

第二层：只读验证器，凭据"验活"但不"越活"

侦察中最敏感的环节是验证：扫出一个泄露的 API Key，它是死的还是活的？Claude-OSINT 的答案是 9 个只读凭据验证器（Read-only validators），定义在 skills/offensive-osint/SKILL.md 的 §23 中：

验证器	只做一件事	结果
Postman API Key	`GET /me`查自身身份	200=存活，401=失效
AWS Access Key	`sts:GetCallerIdentity`	只返回账号 ID 与 ARN
GitHub PAT	`GET /user`	读取登录名与 token 权限范围
Slack Token	`auth.test`	仅验证有效性

设计纪律有三条：

🚫绝不拿验证过的凭据做任何事——除了确认存活，不读数据、不发消息、不改配置
🏷️ 每次验证都打上detectability（可检测性）标签和 UTC 时间戳，让操作者在报告里诚实交代"这个动作会被目标方看到"
⚠️ 明确禁止验证 root 级别凭据等高危操作

简单说：验证器只回答"它是不是活的"，永远不回答"我能拿它干什么"。

第三层：硬边界，把红线写进每个技能

软检查在"入口"，只读原则在"手段"，而每个技能的Do NOT章节（§5）则是最后的硬墙。它不是建议，是明令禁止：

🪪identity-provider-recon：SKILL.md 写明——用户枚举是能力上限，绝不提交任何真实、猜测或泄露的密码；每租户枚举上限 20 个候选，这是生产硬上限而非建议；枚举 oracle 会出现在目标租户自己的审计日志里，因此运行前必须单独做一次更尖锐的授权确认
☁️cloud-saas-exposure：SKILL.md 写明——可以离线解码 AWS 账号 ID，但绝不用它调用 AWS API；可以列桶，但绝不下载桶内对象
✉️email-domain-security：SKILL.md 写明——只读 DNS，不发伪造测试邮件、不做 SMTP 收件人探测

这些"硬边界"的共同风格是把边界画在动作本身：不是"请不要滥用"，而是"这个动作根本不存在于你的能力集里"。

三层防线如何协同工作

用户请求 → ① 软范围检查（授权吗？） ↓ 通过 ② 执行侦察（被动优先、检测感知、遇防御即退避） ↓ 发现疑似凭据 ③ 只读验证（验活不越活、标注可检测性） ↓ 全程 ④ 硬边界（Do NOT 规则 + 排除清单兜底） ↓ 报告交付（置信度 + 严重度 + 证据链）

这套设计的效果在 tests/smoke-test-prompts.md 中有量化体现：56 条提示词自测56/56 PASS，零虚构。更深的技术模型（置信度三级、可检测性分级、资产图纪律）可参阅 docs/architecture.md，各技能的能力覆盖边界则在 docs/coverage.md 中如实拆解。