一位 Cursor Ultra 年费会员在技术论坛发帖，对 Cursor 集成的 Grok 模型表示失望。经测试发现，Cursor 针对 Grok 4.5 和 4.6 版本实施了额外的、极其严格的安全护栏。尽管此前针对 Grok 4.5 存在破限提示词，但在 Cursor 环境下，针对 4.6 版本的常规提示词注入已完全失效。通过技术分析，用户指出 Cursor 并未仅在网关层面进行提示词过滤，而是在后台 API 级别直接植入了一个名为 “offensive_cyber” 的安全 harness。这种深层限制直接禁用了所有涉及安全场景的提示词，包括万能 CTF（Capture The Flag）方式，导致无法进行相关的渗透测试或代码生成任务。由于抓包无法拦截，且请求不在前端处理，这种后端级别的注入使得绕过难度极高。经过一天的尝试，用户未能找到有效的绕过方案。对比官方的 Grok Build，Cursor 版本的安全限制过于严苛。因此，该用户并不推荐为了使用 Grok 而购买 Cursor，建议等待后续社区出现新的破解方案。
事件分析
此次事件揭示了 AI 编程工具在模型集成层面的技术差异与合规风险。Cursor 作为商业化 IDE，为了符合平台安全合规要求，对上游模型进行了二次封装和深度的内容干预。用户提到的 “offensive_cyber” harness 表明，这种限制已深入至 API 调用的后端逻辑层，这远比简单的提示词拦截更难绕过。对于期待利用 Grok 进行安全研究或 CTF 练习的开发者而言，这种平台级的“阉割”实际上削弱了模型的原生能力。这也反映出当前 SaaS 编程工具链中，平台方对模型输出内容的绝对控制权，开发者在追求效率的同时，不得不面对模型能力被平台策略限制的现实。
核心观点：平台级安全限制会削弱大模型的原生能力，SaaS 编程工具需在合规性与模型自由度间寻找平衡。
原文链接：Linux.do
