资讯动态

Destructive Command Guard secret_disclosure 包详解:防止 AI Agent 把密钥值读进会话记录

发布时间:2026/9/17 14:46:24 来源:尧图企业网站定制
Destructive Command Guard secret_disclosure 包详解防止 AI Agent 把密钥值读进会话记录【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guardDestructive Command Guarddcg的secret_disclosure包专门拦截那些会把机密值API Key、数据库凭据、证书等打印到 Agent 可见输出的密钥管理器命令。与传统 防止误删误改 的保护不同它解决的是 AI Agent 场景下独有的风险——一次op read op://prod/api/key或vault kv get并不会破坏任何资源却会把生产凭据永久写入 Agent 的对话记录transcript。本文基于仓库内 secret_disclosure 包文档 与实现源码 src/packs/secrets/disclosure.rs完整讲解该包的启用方式、关键词过滤、安全/破坏模式、Windows 绕过防护与按规则白名单策略。一个披露而非破坏的独立保护维度dcg 的大部分 pack 关注的是破坏性操作drop 表、force push、rm -rf而secret_disclosure把策略目标从 prevent mutation防止变更切换到 prevent disclosure防止披露。src/packs/secrets/disclosure.rs 文件头部的注释对此有明确说明//! Opt-in guard against commands that expose secret values to agent-visible output. //! //! This is deliberately separate from the ordinary secrets.* destruction //! packs. It changes policy from prevent mutation to prevent disclosure //! and therefore remains opt-in even when a provider pack is enabled.这个设计有一个直接后果即使你启用了secrets类别包含 Vault、AWS Secrets Manager、1Password、Doppler、Infisical 五个供应商 packinfisical secrets get API_KEY --plain这类读取命令仍然会被放行——因为供应商 pack 只拦改/删不拦读。只有显式启用secret_disclosure包后读取类的披露规则才会生效。源码中的测试provider_read_is_allowed_until_disclosure_pack_is_enabled精确固化了这一行为仅启用secrets.infisical时该命令不拦截同时启用secrets.infisical与secret_disclosure后才会以infisical-secrets-get-output规则被拦截且结果的pack_id指向secret_disclosure。另一个测试provider_safe_patterns_do_not_suppress_disclosure_policy还验证了各供应商 pack 自带的安全模式不会意外豁免披露策略。因此推荐的组合是供应商 pack 披露 pack同时启用前者挡住删库改密后者挡住读密外泄。启用 secret_disclosure 包secret_disclosure是一个顶层 pack不是某个类别下的子 pack默认不启用属于 opt-in 项。启用方式与其他 pack 一致编辑~/.config/dcg/config.toml[packs] enabled [secret_disclosure]也可以用环境变量临时启用DCG_PACKSsecret_disclosure详见 docs/packs/README.md 与 docs/configuration.md 的 Pack Configuration 一节。验证是否生效可以用 dcg 的测试模式直接对命令做策略判定dcg test op read op://prod/api/key启用后该命令会被拦截未启用时则放行。从源码结构看该包注册在 pack 注册表 src/packs/mod.rs 中PackEntry::new( secret_disclosure, [infisical, doppler, vault, aws, secretsmanager, ssm, op], secrets::disclosure::create_pack, ),它还被列入careful_company_running_windows公司预设的成员清单该预设面向 Windows 上带绕过能力的 Agent成员表固化在二进制中见 src/packs/mod.rs 中 Secret stores 分组即启用该预设时披露保护自动随附。此外注册表中将其划在 Tier 10services 层cicd.*、email.*、secrets.*、secret_disclosure等影响 pack 的评估分组归属。关键词快速拒绝quick-reject过滤原 文档 列出的关键词如下——命令中包含其中任一词时才会真正走到该包的模式匹配infisicaldopplervaultawssecretsmanagerssmop从 Pack 结构定义 可以看到keywords字段用于快速拒绝命令不含任何关键词时直接跳过该包不执行任何正则。注册时注册表会用这些关键词构建 Aho-Corasick 自动机keyword_matcher字段使关键词检测为 O(n) 单次扫描。might_match方法src/packs/mod.rs优先走自动机缺失时回退到逐关键词的子串搜索。这个机制对性能敏感场景很关键hook 是每次 Agent 执行命令时都会触发的绝大多数命令git status、ls、npm test都不含这些关键词secret_disclosure包在关键词阶段就被排除正则开销为零。注意op是单字符词aws/ssm也是短词快速拒绝只决定要不要进入正则最终是否拦截仍由破坏模式 可执行文件范围限定双重把关见下文避免误伤。安全模式Safe Patterns帮助命令不受影响匹配到安全模式的命令直接放行跳过后续破坏模式检查。该包定义了两条安全模式源码 src/packs/secrets/disclosure.rs模式名正则用途secret-cli-dashed-help(?i:\b(?:infisical\|op\|doppler\|vault\|aws)(?:\.exe\|\.cmd\|\.bat\|\.com)?\b)[^\|;]*\s(?:-h\|--help)(?:\s\|$)五条密钥 CLI 的-h/--help帮助aws-secret-read-help(?i:\baws(?:\.exe\|\.cmd\|\.bat\|\.com)?\b)(?:\s--?\S(?:\s\S)?)*\s(?:secretsmanager\s(?:get-secret-value\|batch-get-secret-value)\|ssm\s(?:get-parameter\|get-parameters\|get-parameters-by-path\|get-parameter-history))\shelp(?:\s\|$)AWS CLI 子命令的help用法第二条针对 AWS CLI 的习惯用法——AWS CLI 用尾部help单词代替--help如aws ssm get-parameter help且前缀可带--region等全局参数因此正则允许--?\S(?:\s\S)?形式的任意选项对穿插在aws与子命令之间。测试help_for_protected_commands_remains_available验证了infisical secrets --help、vault kv get -h、aws secretsmanager get-secret-value help等九条帮助命令全部放行拦截读密钥不代表 Agent 无法查看命令用法。破坏模式11 条拦截规则及其正则原 文档 列出的全部 11 条破坏模式如下严重度均为highHigh 在 dcg 中的语义是默认拦截可按规则 ID 白名单放行见 Severity 定义模式名拦截原因严重度infisical-secrets-list-outputinfisical secrets 会把所选的全部密钥值打印到 stdouthighinfisical-secrets-get-outputinfisical secrets get 会把请求的密钥值打印到 stdouthighinfisical-export-outputinfisical export 会输出一整套密钥值highinfisical-dynamic-lease-create-outputinfisical dynamic-secrets lease create 会发出新签发的凭据highonepassword-read-outputop read 会把 1Password 字段值打印到 stdouthighonepassword-item-get-outputop item get 可能把机密字段打印到 stdouthighonepassword-document-get-outputop document get 会输出受保护文档内容highdoppler-secrets-outputdoppler secrets get/list/download 会发出密钥值highvault-read-outputvault read/kv get 可能把密钥值打印到 stdouthighaws-secretsmanager-read-outputaws secretsmanager get-secret-value 与 batch-get-secret-value 会打印存储的密钥值highaws-ssm-decrypted-read-outputaws ssm 解密读取会打印 SecureString 值high每条规则在源码中都带有一段解释 替代方案文本拦截时展示给 Agent/操作者。以 Infisical 为例disclosure.rsinfisical secrets列表输出The bare secrets command emits values into the terminal and agent transcript. Useinfisical run -- commandto inject values directly into a child process.infisical secrets getReading values through stdout records them in the agent transcript. Useinfisical run -- commandwhen the value is needed by a process.infisical exportExport output contains live credentials and can enter the agent transcript or an unprotected file. Prefer process injection withinfisical run.infisical dynamic-secrets lease createA newly created lease returns credential values. Running this in an agent shell places those credentials in the transcript.其他工具的替代方案遵循同一思路1Password 用op run -- command或 secret reference 直接让目标进程消费Doppler 用doppler run -- commandVault 建议通过受保护的注入流程把值直接交给消费进程而不是经 Agent 可见的终端回传。核心正则的结构也值得说明取自源码infisical-secrets-list-output: (?i:\binfisical(?:\.exe|\.cmd|\.bat|\.com)?\b)(?:\s--?\S(?:\s\S)?)*\ssecrets(?:\s--?\S(?:\s\S)?)*(?:\s*(?:\d*[]|\*|[|;])|\s*$)(?i:\b...\b)只把可执行文件名部分设为大小写不敏感并兼容.exe/.cmd/.bat/.com等 Windows 拼写(?:\s--?\S(?:\s\S)?)*允许任意数量的--flag value/--flagvalue选项穿插如--envprod --path/gitlab、--domain https://...列表规则的结尾(?:\s*(?:\d*[]|\*|[|;])|\s*$)还覆盖了重定向与管道infisical secrets --envprod secrets.txt、1secrets.txt、* secrets.txt都会被拦——把值写进 Agent 自选的文件同样是披露windows_executable_spellings_and_redirected_lists_are_blocked测试专门验证了这一点aws-ssm-decrypted-read-output则要求命令中出现--with-decryptionaws ssm get-parameter --name /public/config不带解密参数的普通读取不受该规则影响见测试injection_metadata_and_mutation_do_not_match_disclosure_rules。测试value_emitting_commands_are_blocked覆盖了 16 条典型拦截样例从infisical secrets get API_KEY --plain --silent、aws --region us-east-1 secretsmanager get-secret-value --secret-id prod/api到aws ssm get-parameters-by-path --path /prod --with-decryption是理解每条规则实际命中范围的最直接材料。规则的作用域只拦值发射不误伤注入与变更dcg 的模式带有可选的executables范围限定字段issue #289见 DestructivePattern 结构secret_disclosure的所有规则都声明了executables [infisical]/[op]/[doppler]/[vault]/[aws]。评估器会解析命令段的 argv0剥离sudo/env包装与前导赋值、取 basename、去扩展名、ASCII 大小写不敏感只有该命令段确实由对应可执行文件主导时规则才生效动态 argv0含 shell 展开永远不匹配。这套机制带来几组重要的不匹配边界测试injection_metadata_and_mutation_do_not_match_disclosure_rules全部固化进程注入不拦infisical run --envprod -- npm start、op run -- node server.js、doppler run -- npm start——值直接注入子进程不经过 stdout变更/删除不拦那是供应商 pack 的职责infisical secrets set、infisical secrets delete、vault kv put元数据操作不拦op item list --vault Production、infisical secrets folders get、aws secretsmanager describe-secret。测试quoted_command_examples_are_not_treated_as_invocations还验证了echo op read op://prod/api/key、printf %s infisical secrets get API_KEY、command -v vault这类提及而非调用的写法不会命中——引用中的密钥命令示例不会被当作真实调用。Windows 可执行文件拼写与 cmd 批处理后缀Agent 在 Windows 上经常以INFISICAL.EXE、aws.bat、op.com形式调用工具。两条防线保证这些拼写绕不过披露策略每条正则内建扩展名兼容(?:\.exe|\.cmd|\.bat|\.com)?出现在每个可执行文件锚点里C:\Tools\INFISICAL.EXE secrets --envprod secrets.txt、VAULT.EXE kv get secret/prod/api均被拦截测试windows_executable_spellings_and_redirected_lists_are_blockedcmd 批处理后缀回归测试cmd_batch_suffixes_cannot_bypass_disclosure_policy通过完整注册表REGISTRY.check_command验证infisical.cmd secrets get API_KEY --plain、aws.bat secretsmanager get-secret-value --secret-id prod/api、op.com read op://prod/api/key三条命令全部拦截防止去掉 .exe 换成 .cmd这类绕过。按规则白名单Allowlist Guidance原 文档 给出的白名单配置完整保留如下。由于 High 严重度默认拦截但允许按规则 ID 放行你可以精细地只放行某一条规则放行单条规则[[allow]] rule secret_disclosure:pattern-name reason Your reason here例如只想放行 AWS SSM 解密读取其他披露规则仍然生效[[allow]] rule secret_disclosure:aws-ssm-decrypted-read-output reason Ops runbook requires parameter audit in this repo放行整个包谨慎使用[[allow]] rule secret_disclosure:* reason Your reason here risk_acknowledged true通配符放行需要显式附加risk_acknowledged true把我理解这是全量豁免作为配置约束固化下来。白名单规则 ID 的格式是pack_id:pattern_name规则名即上表 11 个模式名之一。除白名单外dcg 还支持[policy.rules]按规则调整决策模式如降级为warn见 docs/configuration.md 的 Decision Policy 一节DCG_BYPASS1是全局逃生舱不建议在生产策略中使用。验证手段用 dcg 自己测试策略不接 hook 也能验证该包行为用dcg test对具体命令做判定# 未启用 secret_disclosure 时放行读密钥不在供应商 pack 管辖范围 dcg test op read op://prod/api/key # 启用后拦截输出应指向 packsecret_disclosure、 # patternonepassword-read-output dcg test op read op://prod/api/key # 帮助命令始终放行 dcg test aws ssm get-parameter help回归测试位于 src/packs/secrets/disclosure.rs 的mod tests可运行cargo test secrets::disclosure复核全部行为契约pack 契约模式名唯一、可编译、均带 reason、16 条值发射命令拦截、Windows 拼写与重定向拦截、cmd 批处理后缀防绕过、注入/变更/元数据命令不匹配、供应商 pack 与安全模式不得豁免披露策略、帮助命令可用、引用示例不误判。pack_contract测试还依赖 test_helpers 中的assert_blocks_with_pattern/assert_allows等断言工具保证命令 → 精确规则名的一一映射不被改动悄悄破坏。小结secret_disclosure是 dcg 中首个把防护目标从破坏转向披露的 pack设计要点可以归纳为独立且 opt-in与secrets.*供应商 pack 正交启用后者不会隐式开启披露策略反之亦然关键词快速拒绝 可执行文件范围限定双层过滤既保性能又避免误伤注入run --与变更类命令11 条 High 规则覆盖五大工具Infisical 4 条、1Password 3 条、Doppler 1 条、Vault 1 条、AWS 2 条全部附带为什么拦 怎么安全替代的拦截文案Windows 拼写与重定向绕过有专项回归测试防止.exe/.cmd/.bat/.com与 file成为旁路按规则 ID 白名单单条精确放行与全量豁免risk_acknowledged两种粒度都可用。对于需要 Agent 接触真实密钥管理器的团队供应商 pack secret_disclosure是当前仓库推荐的完整组合具体启用与白名单配置见 docs/packs/README.md、docs/packs/secret_disclosure.md 与 docs/configuration.md。【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价