dcg交互模式双因子验证：如何防止AI代理自动绕过安全提示

dcg交互模式双因子验证如何防止AI代理自动绕过安全提示【免费下载链接】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_guarddcgDestructive Command Guard是一款专为 AI 编程代理打造的安全钩子它在rm -rf ./src、git reset --hard这类危险命令真正执行之前就把它们拦下来。但它还有一个容易被忽略的隐患——当 dcg 弹出安全提示等待人工确认时如果 AI 代理遭遇了提示词注入它可能会自动替你把确认输掉。这篇文章带你看懂 dcg交互模式的双因子验证是如何让解除封锁的权力只留在人类手里的。️ 隐患会自己按 y的 AI 代理先看 dcg 守护的是什么场景AI 代理Claude Code、Codex CLI、Cursor 等在终端里干活dcg 站在它和 Shell 之间。信任边界是这样的AI 代理不可信 → dcg 可信 → Shell 可信。问题在于交互确认这个环节。想象这条攻击链AI 代理发出破坏性命令比如git reset --hard HEAD~5dcg 拦截并弹出交互式安全提示一条提示词注入藏在 README、issue 或网页里让代理自动回应提示代理把要求的验证内容输入封锁被解除dcg 的防护形同虚设。这个攻击不需要任何特殊权限——只要能控制代理的输入输出就够。所以 dcg 的设计目标是明确的只有人类能成功应答这个提示任何程序化应答都必须失败。 双因子验证随机验证码 × 超时窗口dcg 的交互模式采用了双因子组合两个因子缺一不可因子机制作用① 随机验证码每次拦截都生成一个全新的短验证码默认 4 位大小写不敏感无法预脚本、无法重放② 超时窗口必须在 5 秒内可配 1–30 秒输入倒计时结束自动拒绝阻断慢速自动化分析验证码的几个细节值得注意密码学安全随机数生成不可预测字符集刻意剔除 i、l、o、0、1 等易混淆字符人眼一眼就能认对单次有效同一会话内已用过的码不会重复出现超时或输错就换新码重计默认最多尝试 3 次连续失败会触发锁定防暴力穷举。更关键的第一道闸门TTY 检测双因子之前还有一层环境闸门这是防 AI 代理绕过的核心stdin 不是 TTY管道输入→ 判定来自程序/代理 → 交互模式直接不可用命令照拦不误。人类在终端里操作才有 TTY而代理发来的输入几乎必然是管道——这一条就把绝大多数自动应答从根上掐死了CI 环境默认禁用交互模式识别CI、GITHUB_ACTIONS、JENKINS等变量TERMdumb等不适合交互的终端同样拒绝。对应地各种自动化攻击向量各有克星攻击向量dcg 的应对预脚本式绕过验证码随机无法预先写死回答慢速自动化分析超时窗口不给想一想的时间重放攻击验证码一次性、限时暴力穷举限时内尝试次数有限 失败锁定终端转义注入伪造提示框展示前清洗 CSI/OSC 转义序列与控制字节人看到的提示一定就是原始内容最后一点容易被忽视被拦截的命令文本在显示前会经过专门的清洗见 src/interactive.rs恶意命令无法用转义序列伪造提示边界或改掉终端标题来误导正在人肉审查的你——毕竟交互提示的全部价值就在于人类亲眼看到代理想跑什么。 验证通过后四级放行范围验证码 超时都通过后dcg 不会直接放行而是让你选择放行范围把信任精确到最小粒度范围生效时间适用场景Once仅本次执行就这一次Session当前终端会话这一轮调试Temporary24 小时短期批量操作Permanent永久写入白名单确认安全的高频命令如果只是偶尔误报也可以走 dcg 的 allow-once 流程被拦截时输出的 6 位数字码配合dcg allow-once code生成一个限定精确命令、24 小时过期、且只作用于当前项目目录的临时例外全程留痕可审计。细节见 docs/allow-once-usage.md。⚙️ 三步开启交互模式交互模式默认关闭安全第一需要人工介入确认时才显式开启。第 1 步确认 dcg 已安装安装脚本或包管理器均可参见 README.md。第 2 步在~/.config/dcg/config.toml中加入配置[interactive] enabled true # 主开关 verification code # code随机验证码推荐 # command完整重输命令偏执模式 # none无验证不推荐易被自动化 timeout_seconds 5 # 响应窗口1–30 秒 code_length 4 # 验证码长度4–8 位 max_attempts 3 # 失败锁定阈值 lockout_seconds 60 # 锁定时长第 3 步验证生效——让代理或你自己触发一条危险命令比如git reset --hard HEAD应看到带倒计时和安全框的拦截提示输错验证码则拒绝并生成新码。小贴士verification command要求用户逐字重输整条命令对自动化几乎无法应付但对长命令体验较差适合高敏环境当偏执模式使用。 设计取舍为什么不用数学题或语义问答在 docs/security-model.md 中dcg 团队评估了 5 种验证方案结论很有启发性数学题/传统 CAPTCHA对 LLM 而言7 3 ?是零成本无效语义验证请解释这条命令的作用LLM 恰恰擅长生成天衣无缝的解释无效且复杂完整命令重输安全性最高但体验差降级为可选的偏执模式随机码 超时自动化抵抗力最高、实现简单、体验可控胜出。这套组合的边界也很诚实它防的是标准 AI 编程代理的自动化绕过不承诺防御视觉 OCR 极速响应的多模态超级代理文档中已列出动画验证码、硬件密钥等未来方向。✅ 最佳实践清单 没有明确的人工确认需求时保持交互模式关闭 高频但确认安全的命令优先用永久白名单dcg allowlist add消除反复解锁而不是依赖交互提示 无值守/全自动跑代理的机器上可配合DCG_UNVERIFIED_DECISIONdeny等失败即拒绝策略避免任何自动应答者替你做决定verification none等于只按一个回车就能放行不建议在 AI 代理活跃的环境使用 团队环境可加require_env变量进一步限定谁能触发交互模式。 延伸阅读docs/security-model.md — 交互模式完整威胁模型与设计文档src/interactive.rs — 双因子验证、TTY 检测与提示框渲染的源码实现docs/allow-once-usage.md — 24 小时临时例外allow-once工作流docs/configuration.md — 全部配置项参考README.md — 项目总览、50 安全包与安装指南一句话总结dcg 把谁来解除封锁这道题设计成了只有人类能答的题——TTY 闸门挡住程序化输入随机码加超时窗口挡住预脚本与重放四级放行范围再把信任收束到最小。AI 代理继续高效干活而那把放行钥匙始终在你手里。【免费下载链接】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），仅供参考