用 AIGoCode 做代码安全审计：任务开始前先写清授权范围

先给审计任务一份清楚的委托范围

准备让 AI 帮你审阅鉴权逻辑、分析错误日志或检查修复方案时，先写清楚授权范围，能够减少“看哪些代码、允许做什么、结果交给谁”上的歧义。

AIGoCode 使用政策说明，合法、授权、低风险的安全研究、代码审计、日志分析、防御性检测和漏洞修复通常可以使用本服务；同时要求拥有明确授权，避免访问、复制、破坏或泄露第三方系统和数据，并对可直接用于攻击、持久化控制、凭据窃取、规避检测或扩大攻击面的内容作出限制。

本文针对自有或已经取得明确授权的防御性代码审计，给出一份任务说明的写法。文中的整理步骤是工作建议，不代表 AIGoCode 另行提供审计认证、专用扫描器或自动安全保证。

一、系统范围：写到仓库、模块和环境

“帮我检查这个项目有没有漏洞”过于宽泛。建议先把授权范围收敛到本次确实需要检查的材料，例如：

• 项目负责人允许审阅的某个仓库及具体版本。
• 本轮涉及的登录校验、权限判断或数据访问模块。
• 本次提供的虚构测试样本与已脱敏日志。
• 明确排除的第三方服务、生产账户和无关目录。

上述例子用于帮助描述范围，不能替代真实授权。对托管在自己账号里的材料，也应核对自己是否有权提交其中的第三方代码或客户资料。

如果审计中发现问题可能涉及另一个服务，可以先记录依赖关系和需要确认的权限。新增系统与数据不在原范围内时，建议在补充授权前暂停扩展检查，避免任务悄悄变成对未知系统的探测。

二、资料权限：能看到不等于能交给外部服务

使用政策明确要求，不得提交无权使用的代码、数据、文档、密钥、个人信息、商业秘密、受版权保护内容或其他第三方材料。

因此，整理输入时建议逐项核对：

对拿不准的内容，先问资料负责人。不要仅凭仓库可访问、文件已下载或属于测试环境，就推定所有内容都可以提交。

三、允许动作：先做材料内的防御性审阅

任务说明应当写出本次允许的动作。比如：“只根据提供的代码和虚构样本分析权限检查是否一致，指出相关分支、可能影响和修复建议；不要访问外部系统，不使用真实凭据，也不执行任何生产写入。”

这段话是一种委托写法，并不表示模型平台本身会自动执行或强制隔离这些动作。如果你还配置了编程 Agent、命令行工具或其他执行能力，应由负责人另行检查这些工具的权限和实际行为。

使用政策对安全研究的支持带有授权、低风险和防御性用途条件。任务是否合适，取决于具体输入、动作和期望结果，不能只凭标题写着“安全研究”来判断。

四、期望输出：让发现便于人工复核

建议要求每一项发现都包括下面几部分：

1. 位置与现象：对应哪个文件、函数或代码分支，观察到什么。
2. 依据与条件：哪些输入或调用路径与判断有关，哪些信息尚未提供。
3. 影响范围：在已有证据内解释风险，不把一个可疑点扩大成已经发生的数据泄露。
4. 修复建议：优先给出权限校验、输入约束或错误处理层面的防御性改进。
5. 验证建议：用授权环境和虚构样本提出可由负责人执行的检查项。

要求把“不确定、需补材料”单独列出来，也有助于避免把推测误当成确定缺陷。不要要求输出可直接用于攻击、获取凭据、维持控制或绕过检测的内容。

五、验证责任：审计结论和修复仍需核实

使用政策提醒，AI 输出可能不准确、不完整、过时、重复、带有偏差或不适合具体场景；在展示、发布、发送或嵌入输出前，应自行审核、测试和过滤，并承担相应责任。

具体到代码审计，可以安排负责人逐项确认：发现是否能由代码逻辑支持，修复是否改变了预期权限，正常用户路径是否仍然可用。测试和执行都应在已确认的授权范围内进行。模型说“检查通过”不能代替这些验证，也不能作为项目已经安全的证明。

如果你使用的是可执行命令的编程工具，还可以结合AI 编程沙箱的安全边界检查工具权限；本篇聚焦审计委托范围，工具自身的隔离机制需要另行核对。

可以填写的任务说明

提交审计材料前，可以先完成这份简表：

• 负责人及授权依据：谁批准本次审计，适用到哪些项目与资料。
• 本次范围：仓库、版本、模块及明确排除项。
• 输入材料：仅提供哪些代码和样本，资料权限是否已确认。
• 允许动作：只读审阅、分析和修复建议；其他动作逐项列明。
• 输出要求：位置、证据、前提、影响、建议和待确认项。
• 人工验证：由谁复核，在哪个授权环境验证。
• 范围变化处理：发现需要新增系统、资料或动作时，先暂停并补充确认。

写完以后，再核对AIGoCode 使用政策的当前版本。授权范围清楚、输入有权使用、结果能够人工验证，才便于把一次 AI 辅助分析变成可追溯的防御性审计工作。