AI 输出在接口里只是字符串，进入产品后却可能被渲染成链接、网页、表格、日志或命令。把模型输出统一做一次“过滤”并不能解决问题，因为安全边界取决于它最终进入的上下文。Markdown 链接、HTML 属性、CSV 单元格和 JSON 字符串的风险完全不同。
先标记输出去哪里
浏览器渲染 Markdown 时，要限制危险协议、处理 HTML 标签，并避免把不可信内容插入 innerHTML。生成 HTML 时需要上下文相关转义，不能只替换几个尖括号。导出 CSV 时，单元格以 =``+``-``@ 开头可能被表格软件解释为公式，应按 CSV 注入规则处理。JSON 则要保证严格序列化，不能把模型字符串拼进代码或配置。
日志和终端也有自己的问题。模型可能输出换行、控制字符、伪造日志前缀或终端转义序列，导致审计记录混乱。代码块、Shell 命令和 SQL 片段应默认作为待审查文本，不要因为格式看起来正确就直接执行。
网关能做什么，应用仍要做什么
网关可以给响应增加内容类型、来源、模型和安全标签，限制明显危险的协议和异常长度，保留原始摘要用于排查。最终渲染或执行的应用必须按自己的输出上下文再次编码。一次通用清洗不能代替前端模板安全、CSV 导出库和命令执行审批。
使用 top-api.cc 统一多模型调用时，可以在响应元数据中记录模型和策略版本，帮助发现某个上游更容易输出特殊格式。但网关不应偷偷改变业务文本，最好把“原始输出”和“安全渲染版本”明确分开。
评测用例
- 含链接、图片、HTML 标签和事件属性的 Markdown；
- 以公式字符开头的表格内容；
- 伪造日志、换行和终端控制字符；
- 看似 JSON、实际包含未转义引号的内容；
- 代码、命令和 SQL 片段；
- 多语言、Unicode 控制字符和超长输出。
输出安全的目标不是把所有特殊字符删掉，而是让数据在目标上下文中保持数据身份。测试报告要说明在哪一层编码、谁负责渲染、谁负责审批执行，以及用户是否能看到原始内容被怎样处理。
参考资料：OWASP XSS 和 CSV Injection 防护建议、各前端 Markdown 渲染器和 CSV 库的安全文档。安全规则应随输出媒介分别维护。
如果多个模型共用一套前端和导出流程，可以通过 top-api.cc 统一记录输出策略版本，再在应用层对每种媒介做针对性测试。
Leave a Reply