security-patterns 是来源为 yonatangross/orchestkit 的一个安全技能，定位为构建加固应用时使用的综合安全模式集合。技能地址为 https://www.skills.sh/yonatangross/orchestkit/security-patterns。
用途与结构 该技能围绕若干安全类别组织内容，每个类别包含可按需加载到 rules/ 的规则文件。资料列出的类别与影响级别包括：认证（CRITICAL，涉及 JWT、OAuth 2.1/PKCE、RBAC 与权限）、纵深防御（1 条规则，CRITICAL，涉及多层安全与零信任架构）、输入验证（2 条规则，HIGH，涉及 Zod/Pydantic 模式校验、输出编码与文件上传）、OWASP Top 10（1 条规则，CRITICAL，涉及注入防护与失效认证修复）、LLM 安全（refs，HIGH，涉及提示注入防御、输出护栏与内容过滤）、PII 脱敏（refs，HIGH，涉及使用 Presidio、Langfuse、LLM Guard 进行 PII 检测与编辑）、扫描（upstream，HIGH，涉及依赖审计、SAST（Semgrep/Bandit）与密钥检测）、高级护栏（2 条规则，CRITICAL，涉及 NeMo/Guardrails AI 校验器、红队测试与 OWASP LLM）。资料说明总计 6 个规则文件，跨 4 个类别；标注为 upstream 或 refs 的主题只在此文件保留 ork 增量，即最低标准与关键决策写在本文件，经验教训与内部决策写在 references/ork-delta.md，第一方来源列在“Upstream coverage”中。
主要能力与关键决策 认证方面，资料给出的关键决策为：Argon2id 优于 bcrypt；访问令牌有效期 15 分钟；PKCE 必需；Passkeys 优于 TOTP，TOTP 优于 SMS。纵深防御方面，关键决策为：不可变 dataclass 上下文；查询级租户过滤；LLM 提示中不出现 ID。输入验证方面，关键决策为：允许列表优于阻止列表；始终服务端校验；校验魔法字节而非扩展名。OWASP Top 10 方面，关键决策为：仅使用参数化查询；硬编码 JWT 算法；SameSite=Strict Cookie。LLM 安全方面，关键决策为：ID 绕过 LLM 而非穿过 LLM；归属关系为确定性；审计每个提示。PII 脱敏方面，关键决策为：企业场景用 Presidio；用类型令牌替换；在初始化时使用 mask 回调。扫描方面，关键决策为：用预提交钩子实现左移；阻断 critical/high；使用 Gitleaks 与 detect-secrets 基线。高级护栏方面，关键决策为：用 NeMo 处理流程，用 Guardrails AI 处理校验器；毒性阈值 0.5；发布前与每季度进行红队测试。
使用方式示例 资料提供了若干代码片段作为快速开始。密码哈希使用 Python 的 argon2 库：from argon2 import PasswordHasher；ph = PasswordHasher()；password_hash = ph.hash(password)；ph.verify(password_hash, password)。JWT 访问令牌使用 jwt 库与 datetime，payload 包含 sub、type 为 access，exp 为当前 UTC 时间加 15 分钟，使用 HS256 算法编码。Zod v4 模式校验示例定义了 UserSchema，包含 email、长度 2 到 100 的 name、默认值为 user 的 role 枚举，并使用 safeParse 解析请求体。Langfuse PII 掩码示例定义 mask_pii 函数，用正则将邮箱替换为 [REDACTED_EMAIL]、将形如 123-45-6789 的字符串替换为 [REDACTED_SSN]，然后在 Langfuse(mask=mask_pii) 中使用。
LLM 安全与输出校验 LLM 安全包含上下文分离、提示审计、输出护栏、预 LLM 过滤、后 LLM 归属等参考文件。上下文分离被标为 CRITICAL：敏感 ID 与数据绕过 LLM，绝不穿过 LLM；LLM 只看到内容，映射回实体在之后确定性地完成。资料给出的正确示例将 user_id 与 tenant_id 保存在服务端 context 字典中，提示中只包含文档文本，调用 LLM 后再把 ID 重新附加到结果。输出校验流水线要求每个 LLM 响应在到达用户前必须通过四阶段护栏：模式校验（是否符合预期结构）、接地校验（断言声明的依据是否被源文档支持）、安全校验（毒性、PII 泄漏、提示泄漏，最大毒性 0.5）、大小校验（防止令牌炸弹响应，限制 MAX_OUTPUT_CHARS）。
Claude Code 配置细节 资料记录了若干 Claude Code 的 sandbox 配置。sandbox.network.deniedDomains（CC 2.1.113+）在网络层于 Bash/WebFetch 出口前执行黑名单，支持通配符，可用于提示注入外泄目标、已知恶意注册表、绕过审计的粘贴服务；插件在 src/settings/ork.settings.json 中提供基线列表，项目设置可扩展。sandbox.credentials（CC 2.1.187+）阻止沙箱化 Bash 读取凭证文件与密钥环境变量，mode 为 deny，自 CC 2.1.221 起也可为 mask；资料说明 ork 不提供 sandbox.credentials 基线，因为 CC 只读取插件设置文件中的 permissions 键，用户级或托管设置中可设置对 ~/.aws/credentials、~/.ssh、~/.gnupg、~/.netrc、~/.npmrc 以及可劫持 git-push 认证的令牌环境变量进行 deny，并可与 CLAUDE_CODE_SUBPROCESS_ENV_SCRUB 配合。掩码需要 sandbox.network.tlsTerminate，且只从用户设置、托管设置或 --settings 生效；在 macOS 上文件掩码会回退为 deny。资料还提醒不要写带尾斜杠的 deny 路径，因为在 CC 2.1.223 及之前于 Linux 和 macOS 上可被静默绕过，2.1.224 已修复。
托管设置与权限模型 插件设置遵循三层优先级：托管设置（插件 settings.json，插件作者提供的默认值，用户可覆盖）、项目设置（.claude/settings.json，可被用户覆盖）、用户设置（~/.claude/settings.json，最高权威）。OrchestKit 提供的安全钩子属于托管默认值，用户可以禁用但会收到警告；企业管理员可通过托管配置文件锁定设置。资料指出 CC 2.1.166 修复了托管设置强制问题：此前托管设置中一个无效条目会静默禁用其余所有有效策略的强制，依赖托管配置文件时应要求 2.1.166+ 并在部署前校验文件；同一版本还修复了 allowedMcpServers/deniedMcpServers 使用 ${VAR} 引用时不匹配的问题。CC 2.1.160 起 Claude Code 会在写入 shell 启动文件以及在 acceptEdits 下写入可授予代码执行的构建工具配置前进行提示。权限规则语义（≥ 2.1.166）方面，Read deny 会让文件从 Glob/Grep 中隐藏，deny 工具名接受 glob，显式 WebFetch(domain:…) 会覆盖预批准主机的自动允许，来自其他会话转发的 SendMessage 不携带权限，组织管理规则对整个会话生效。CC 2.1.248 起跨会话回复送达父会话而非子代理，跨会话 SendMessage/ListAgents 在 Bedrock、Vertex 与 Foundry 上以及禁用遥测时也可用。
反模式 资料列出禁止做法：认证中明文存储密码、使用隐式 OAuth 授权、返回“Email not found”造成信息泄露；输入验证中拼接 SQL 字符串、信任 Content-Type 头判断文件类型；LLM 安全中提示里包含 user_id、信任 LLM 生成的 ID；PII 中把原始邮箱写入日志、把未掩码提示传给可观测性客户端。
适用场景与限制 该技能适用于实现认证流程、加固多层安全、校验输入输出、防御 OWASP Top 10 风险、构建 LLM 集成安全护栏以及脱敏可观测性数据等场景。限制方面：大量主题被标注为上游覆盖，本技能不再复述，只保留 ork 增量；部分配置（如沙箱凭证掩码）无法由插件作为基线提供，需操作员在用户或托管设置中配置，且掩码需要 TLS 终止并只在特定平台生效；使用托管配置文件时应要求 CC 2.1.166+。资料未提供安装命令、价格、具体平台支持范围或完整的操作步骤。