做安全这行，被AI"拉黑"的滋味不好受。一位安全从业者的遭遇是：Anthropic以涉嫌违反使用政策为由永久停用了他的账号，OpenAI则自动拒绝了他加入"可信网络访问"白名单（他们称之为Daybreak）的申请，尽管他和对方"无能为力的支持团队"来回沟通了大约一周。

打开网易新闻 查看精彩图片

所有门都对他关上了。攻击者能用上强力模型，而他这个合法的安全从业者，除了祈祷OpenAI别标记他的会话，几乎没别的办法。于是他决定"耍点小聪明"。

先说账号是怎么没的。他使用Claude，仅仅是为了写一个从CSV文件导入数字的脚本，结果一小时后账号就被停用，且没有向真人申诉的机会。他的总结带着自嘲：你千万别去导入CSV。一个只有两列（时间戳加数值）的CSV，换来一个永久封禁。

绕开OpenAI，先算成本账

思路很直接：能不能不用OpenAI？怎么让那个烦人的"此内容无法显示……申请Daybreak以获得更广泛访问权限"的报错消失？答案是改用AWS Bedrock上的Kimi（K3）。他听说Kimi/Moonshot的防护措施更少，甚至可能没有。实测确实可行：K3能完成侦察、识别潜在漏洞，并验证和利用它们。

问题出在钱上。OpenAI和Anthropic每月20美元和100美元的订阅很便宜，而用K3做漏洞挖掘，每个（范围严格限定的）任务大约要花10到50美元，具体取决于任务复杂度。粗略估算，每审查1000行代码约20美元。按每个工作日4个任务算：20美元乘以4个任务、5天、4.5周，就是每月1800美元。

每月1800美元，预算却只有100美元。这个数字确实扎眼。

那为什么不直接订阅Kimi/Moonshot每月20或100美元的套餐？听起来很美，但他们没有清晰的留存政策，也没有明确说明AI输入输出会被如何处理，这对安全敏感工作来说是重大警示信号。这种不透明让人难以相信他们会说到做到。用Moonshot的基础设施，这条路被排除了。

不全交给K3，只换掉一个环节

换个问题：如果不把所有事情都委托给K3呢？到底是什么触发了OpenAI的防护机制？在他的场景里很难得到直接答案——多个智能体、多种技能、多条指令，上下文可能已被污染，而Codex（以及其他类似的执行框架）不会告诉你"是什么"导致OpenAI拒绝运行。

他梳理了自己的漏洞挖掘工作流：

  • 测绘：分析上下文、入口点、用户、权限、部署逻辑等，先弄清面对的是什么；
  • 规划：基于测绘结果列出要执行的检查清单，比如能否注入SQL，或往JWT里塞入alg:none；
  • 筛选候选：编排器为每个检查项启动子智能体，判断它是潜在候选（纳入范围）还是排除；
  • 验证与利用：编排器再启动子智能体，确认问题是真阳性还是误报，尝试让代码做出不该做的事；
  • 报告：汇总所有发现，生成供人查看的报告。

触发OpenAI防护的是第四阶段——实际的验证与利用尝试。那就只在这一阶段把OpenAI换成K3。

难点在于，Codex没法告诉OpenAI"这个子智能体请用你竞争对手的产品"。他发现Opencode支持在子智能体中混搭不同供应商和模型：智能体A用openai/gpt-sol-6.1，智能体B用amazon-bedrock/global.moonshotai.kimi-k3。于是可以建一个专门的K3验证智能体，在验证候选时被启动。

效果是每个任务约4到8美元，即每月约360到720美元，降幅约60%到80%。仍然不便宜，但已是巨大改进。好消息是OpenAI那边不再报错，结果质量看起来也保住了——不过在没有Daybreak访问权限的情况下，很难精确判断。

这个数字离预算仍有距离，但他确信，通过进一步实验和耐心，成本还能压得更低。