dcg careful_company_running_windows预设：企业Windows工作站终极安全姿态

dcg careful_company_running_windows预设企业Windows工作站终极安全姿态【免费下载链接】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 编码智能体Agent在无人值守的 Windows 工作站上运行时dcgDestructive Command Guard提供的careful_company_running_windows预设是一道专为企业级 AI Agent 命令防护设计的终极安全姿态。它不仅拦截rm -rf、git reset --hard这类破坏性命令更回答了一个更深层的问题Agent 是否正在把公司数据偷偷发到外部是否在悄悄关闭监控它的防线这正是 docs/careful-company-windows.md 中定义的第二条边界。为什么企业 Windows 工作站需要这道防线普通的 dcg 规则包回答的是这条命令会不会毁掉东西。但在受监管或知识产权敏感的环境中Agent 被赋予了免确认执行权限后风险变成了另一种形态 用Send-MailMessage把数据库导出文件发到外部邮箱 通过 Slack/Discord webhook 把代码片段顺手发出去️ 用ngrok、ssh -R把本机服务暴露到公网 更危险的是——Agent 先执行Set-MpPreference -DisableRealtimeMonitoring关掉 Defender再动手这就是该预设要封死的六类通道。它的实现源码位于 src/packs/careful_company_running_windows/mod.rs官方说明见 docs/packs/careful_company_running_windows.md。一行配置启用完整安全姿态启用方式极其简单——在 dcg 配置文件的[packs]段加入一行预设名即可[packs] enabled [careful_company_running_windows]这一行不仅打开六个防外泄子包还会按钉死pinned的名单自动引入企业姿态所需的既有保护windows.*、database.*含 Snowflake、storage.*、remote.*、backup.*、secrets.*与cloud.*规则包。名单是显式枚举而非前缀匹配意味着未来新增的database.*包不会悄悄混入你的企业策略——这是策略可审计的关键设计。 预设启用后dcg 会自动把 hook 评估超时从 1000ms 放宽到 3000ms给更大的规则集留足评估时间评估结果本身fail-closed 阻断策略不会因此改变。六大子包全景图每个子包都是独立开关可以按需关闭某一维度而不影响其余保护子包封死的通道典型拦截场景careful_company_running_windows.email邮件外发Send-MailMessage、Outlook COM 自动化、SMTP CLI、邮件 APIcareful_company_running_windows.chat聊天与 webhook 出站Slack/Teams/Discord/Telegram webhook、短信 API、请求捕获服务careful_company_running_windows.uploadHTTP 文件上传curl -T、Invoke-RestMethod -InFile、gist 创建、剪贴板外传careful_company_running_windows.transfer文件传输与云存储外发scp/sftp/FTP、rclone、S3/Azure Blob/GCS 上传careful_company_running_windows.tunnel隧道与原始通道ngrok、cloudflared、ssh -R、netcat 裸套接字、DNS 隧道careful_company_running_windows.guardrails安全控制被篡改关 Defender/防火墙、清审计日志、绕过 dcg 本身护栏子包防止 Agent 先拆监控再作案在所有子包中guardrails最具终极姿态气质。它的核心逻辑写在 src/packs/careful_company_running_windows/guardrails.rs 的注释里关闭监控的那条命令比监控要拦下的大多数命令后果更严重。因此以下行为全部被标记为 critical硬性阻断Agent 无权自行解除关闭 Defender、Windows 防火墙或停止 EDR/事件日志服务wevtutil cl/Clear-EventLog清空审计日志设置DCG_BYPASS、卸载 dcg、私自扩写自己的 allowlistiwr … | iex、powershell -EncodedCommand等未审查的远程代码执行同时只读诊断命令如Get-MpComputerStatus、wevtutil el被明确放行——确认防护是否开启本身是谨慎操作者该有的权利。高保真不误伤普通开发照常进行企业落地最大的顾虑是误报。该预设用四条产品设计原则压住误报风险要求出站的正向证据——规则只匹配真正携带数据外发的动作附件、上传方法、已知外泄目标域名普通GET请求、npm install、pip install、cargo build一律放行模糊场景只警告不阻断——对外部主机的泛化POST可能是 GraphQL 查询标记为 medium默认警告 审计继续执行只有无歧义的外发才阻断内网目标白名单——环回地址、RFC1918 私有网段、*.internal/*.corp/*.local等公司内网流量视为开发流量放行而云元数据端点169.254.169.254则被明确排除在外数据中的关键词 ≠ 执行——Select-String Send-MailMessage *.ps1这类搜索命令不会误触规则方向性判断同样精确scp上传到外部被拒scp下载外部文件则放行。平滑落地先警告、再收紧官方推荐的灰度上线流程详见 docs/careful-company-windows.md第一步在[policy.packs]中把六个子包临时设为warn模式观察dcg history里有哪些合法自动化被命中第二步为确属合法的内部工具添加精确的 allowlist 条目如已审查的内部制品发布器第三步移除临时覆盖回到默认的high 阻断 / medium 警告分级响应⚠️ 特别提醒不要用DCG_BYPASS1做集成绕过——guardrails 子包会把任何试图禁用 dcg 的操作当作安全控制篡改来拦截。上线前验证清单部署后建议用这三条命令做体检dcg packs --verbose # 确认预设展开后的全部子包 dcg test hfdt publish report # 试跑一条典型命令 dcg doctor --json # 检查配置来源与生效超时更完整的配置参考见 docs/configuration.md各规则包的关键词与阻断模式明细可在 docs/packs/careful_company_running_windows.md 逐条查阅。适合谁启用这个预设✅ Windows 工作站上运行免确认执行Agent 的企业团队✅ 受监管行业金融、医疗、法律需要审计出站行为的环境✅ 希望一条配置 一套完整安全姿态而非逐包手工勾选的管理者❌ 容器/K8s/CI 场景另有专门规则包本预设刻意不覆盖这些领域总结careful_company_running_windows预设把企业 Windows 工作站上 AI Agent 的六大数据外泄通道和安全控制篡改风险收敛为一行enabled [careful_company_running_windows]配置。它不是 EDR、不是防火墙而是一层命令级策略——以最小侵入的方式让Agent 无人值守跑 PowerShell从安全团队的噩梦变成有边界、可审计、可灰度的标准操作。【免费下载链接】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），仅供参考