规模化应用生成式 AI 前，需先绘制 LLM 使用与风险图谱

在本次Help Net Security访谈中，The Motley Fool应用与云安全总监Paolo del Mundo探讨了企业如何通过建立防护机制来扩展AI应用规模，同时降低提示注入、不安全输出和数据泄露等生成式AI特有风险。

已部署AI功能团队的首步审计重点

生成式AI以传统威胁模型常忽视的方式扩大了攻击面。新入行的安全从业者应首先了解这类新型漏洞及其防御方法。OWASP大语言模型（LLM）十大风险清单是理想起点，其中列举了提示注入、数据泄露和不安全插件设计等常见漏洞。

这些AI安全问题已引起应用安全负责人的高度警觉。ArmorCode最新调查显示：在使用AI工具遭遇问题的受访者中，92%提及不安全代码问题，83%将缺乏透明度列为首要担忧。同时55%的受访者认为生成式AI相关威胁是其最关注的问题。

企业要确保负责任地使用生成式AI，首先应清点LLM使用情况：调用托管模型、微调自有模型还是运行RAG（检索增强生成）流程？用户群体是内部还是外部？是否涉及敏感数据暴露？是否部署细粒度授权机制？

对待LLM应用应如任何新服务：记录输入输出、访问控制及故障模式。投资能帮助绘制可视化数据流的工具，这些工作应先于部署复杂防御措施。

企业应用集成LLM时的输入/输出净化实践

如同传统Web应用使用WAF识别恶意流量，生成式AI应用也需类似防护机制。这些安全护栏会对输入输出进行双重检查：

• 输入侧：系统在请求到达AI模型前，就能检测提示注入尝试、策略违规及越权查询
• 输出侧：过滤模型不应泄露的信息，包括个人身份信息（PII）、内部文档或超出设定范围的回答。例如专用于入职指导的LLM，不应回答薪资等级或财务数据等咨询

这些实时执行的策略边界构成最后防线。虽不能替代访问控制，但能大幅降低漏洞利用可能性。

自研LLM微调与托管的关键安全考量

微调（Fine-tuning）是通过专业数据集继续训练预训练模型的过程，可能暴露代码、内部文档乃至敏感客户数据等知识产权。若无防护措施，攻击者可通过特定话术提取这些信息。

前述调查中37%的受访者认为，软件开发缺乏生成式AI监管是最大应用安全挑战。因此以下安全要素尤为重要：

• 训练数据净化：微调前清除数据集中的密钥、凭证、PII及专有信息
• 模型输出测试：通过红队设计的提示词主动测试模型是否存在记忆内容泄露
• 访问控制与审计日志：限制模型访问权限，记录所有使用行为以便事件响应
• 模型部署卫生：确保API等服务基础设施能防御注入、速率限制绕过等常见Web威胁
• 安全模型托管：防止底层模型文件及权重参数遭篡改或外泄
• 数据溯源追踪：保留模型训练数据记录以满足合规要求

安全团队应将LLM视为高价值资产进行保护。

生成式AI红队测试工具推荐

生成式AI投入生产环境时，红队测试应纳入软件开发生命周期（SDLC）。Lakera Red和Straiker Ascend AI等平台能自动化发现LLM应用的漏洞，模拟提示注入、越狱攻击和代理逃逸等攻击场景，堪称持续运行的专属渗透测试工具。

关键是要将这些工具集成至发布流程，而非作为一次性检查。ArmorCode等应用安全态势管理（ASPM）平台还能整合渗透测试结果，通过AI辅助研判修复优先级。

Lakera的Gandalf等教育类工具虽非正式测试平台，但能让开发团队亲身体验LLM如何被轻易操纵——安全意识教育始终是防御体系的重要组成部分。

AI功能部署至生产环境的CI/CD管道控制要点

所有影响模型行为的要素（如提示词、系统消息、检索逻辑）都应视同代码管理：进行版本控制、代码审查，并纳入标准变更管理流程。

自动化测试需覆盖功能与行为验证。若更新导致模型产生敏感信息幻觉或违反策略，应在预发布环境而非生产环境捕获问题。

扫描微调输入中的PII或风险内容，验证模型制品后再部署，严格限制生产环境推理设置和提示模板的修改权限。变更聊天机器人行为应比部署后端服务更具管控难度——LLM应遵循同等安全标准。