安全答辩里，最危险的回答往往特别短：“数据绝不外流”“模型不会越权”“已经用了国密，所以合规”。这些话把很多不同边界压成一个保证。更有用的答辩方式，是让每个问题对应一段数据流、一组配置和一个反例测试。
六个问题应落到六份证据
| 数据到底去哪里 | 推理、嵌入、遥测、日志、备份的数据流 |
| 谁能读取哪些资料 | 身份来源、租户/岗位权限和越权反例 |
| 模型能执行什么动作 | 工具白名单、动作级裁决与审批 |
| 网络隔离是否真的生效 | 执行环境、网络插件、出口与DNS测试 |
| 密钥与日志如何管理 | 租约、撤销、日志字段及保留策略 |
| 出错后谁能停止 | 停用入口、责任人、回退与通知流程 |
这六类材料没有固定的“合格比例”。例如日志可能完全留在内网，但用于嵌入的文本仍被发送到外部服务。必须按每条实际路径确认，不能拿主模型的部署位置代替全部组件的数据位置。
协议支持不等于系统已经接好
MCP的2025-06-18授权规范区分HTTP传输授权与STDIO从环境取凭据的方式。评审应核对实际传输、资源服务器和凭据范围，而不是只在架构图上贴一个OAuth标签。协议原文
Kubernetes文档说明NetworkPolicy需要网络插件支持才会实际执行。创建YAML对象成功，不能替代出口拒绝和跨命名空间连接测试。网络策略文档
采用密码标准，仍要解释密钥与实现
如果方案提到SM9，应使用正确的GB/T 38636-2020编号，并核对具体采用的算法、实现、证书和适用要求。标准存在不说明某个软件通过了测评，更不能直接推出整个业务系统已经合规。国家标准公开页
METR于10月22日公开的监控评估摘要，明确针对7月21日及之前的历史系统，并说明没有验证厂商后来关于补丁的声明。把评估时点与未验证范围写清楚，正是安全答辩值得借鉴的做法。评估摘要
本文没有运行集群、网络攻防或密码实现测试，也没有给任何项目出具合规结论。可以先准备一份逐项证据目录，再安排有授权的测试；无法证明的能力就写成待验证项，并给出责任人和完成条件。
