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 工作站上运行时，dcg（Destructive 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、邮件 API
careful_company_running_windows.chat	聊天与 webhook 出站	Slack/Teams/Discord/Telegram webhook、短信 API、请求捕获服务
careful_company_running_windows.upload	HTTP 文件上传	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、私自扩写自己的 allowlist
• iwr … | iex、powershell -EncodedCommand等未审查的远程代码执行

同时，只读诊断命令（如Get-MpComputerStatus、wevtutil el）被明确放行——"确认防护是否开启"本身是谨慎操作者该有的权利。

高保真不误伤：普通开发照常进行

企业落地最大的顾虑是误报。该预设用四条产品设计原则压住误报风险：

1. 要求"出站的正向证据"——规则只匹配真正携带数据外发的动作（附件、上传方法、已知外泄目标域名），普通GET请求、npm install、pip install、cargo build一律放行
2. 模糊场景只警告不阻断——对外部主机的泛化POST（可能是 GraphQL 查询）标记为 medium，默认"警告 + 审计"继续执行；只有无歧义的外发才阻断
3. 内网目标白名单——环回地址、RFC1918 私有网段、*.internal/*.corp/*.local等公司内网流量视为开发流量放行，而云元数据端点（169.254.169.254）则被明确排除在外
4. 数据中的关键词 ≠ 执行——Select-String "Send-MailMessage" *.ps1这类搜索命令不会误触规则

方向性判断同样精确：scp上传到外部被拒，scp下载外部文件则放行。

平滑落地：先警告、再收紧

官方推荐的灰度上线流程（详见 docs/careful-company-windows.md）：

1. 第一步：在[policy.packs]中把六个子包临时设为warn模式，观察dcg history里有哪些合法自动化被命中
2. 第二步：为确属合法的内部工具添加精确的 allowlist 条目（如已审查的内部制品发布器）
3. 第三步：移除临时覆盖，回到默认的"high 阻断 / medium 警告"分级响应

⚠️ 特别提醒：不要用DCG_BYPASS=1做集成绕过——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