AI 问数安全 PoC 怎么验收？一份含失败用例的测试表

AI 问数的安全 PoC，关键不是让系统成功回答十个问题，而是让越权、写入、模型不可达和身份失效等请求按预期失败。企业应提前写下测试身份、预期结果和取证方式，再让数据、安全、业务三方共同复测。本文给出一份可改写的测试表；示例均为演练数据，不是客户实施结果。

先准备一个能判断对错的样本

假设某零售企业有 A 店和 B 店。测试库各放两笔订单：A 店 100 元、200 元，B 店 300 元、400 元，另有一个仅财务可见的 customer_phone 字段。准备 A 店店员、B 店店员、财务、项目管理员四个身份，并记录每个身份被授予的表、字段和行范围。

不要只用管理员账号演示。管理员看到全部订单，无法证明店员访问范围受到限制。网页、飞书、嵌入页和 API 若都在上线范围内，还要分别核对入口身份映射；网页测通不代表其他入口自然继承相同身份。

十项测试，按层写清证据

第 9 项特别容易写错：请求若在入口或权限前置阶段被拒，不能预设它一定进入智能体审计日志。应实测拒绝发生的位置，并确定从哪个系统的日志取证。若一次越权请求在任何地方都无法定位，这项就没有通过。

把一项测试写成可复测记录

以“A 店店员问两店总销售额”为例：

1. •步骤：用 A 店店员身份从正式使用入口发问“今天 A 店和 B 店合计销售额是多少？”
2. •预期：系统不返回 B 店的 700 元，也不在执行 SQL 中读到 B 店订单；如果只能回答 A 店数据，应明确说明访问范围。
3. •实际：记录回答原文、可见结果和是否执行查询。不要用一句“已拦截”代替证据。
4. •证据：保存当时角色和行策略配置、查询条件、SQL 或拒绝信息、相关日志及测试时间。
5. •复测：调整策略后，先确认 A 店仍能查自己的 300 元，再重新试跨店问题，防止安全配置把正常查询一并关闭。

“结果没显示 B 店金额”只是一个观察点。还要检查生成的查询有没有触及未授权行，以及导出、分享、工具调用等其他路径是否能把结果带出。

产品控制与企业控制要分开

AskTable 的公开文档说明了字段可见性、行级过滤、只读 SQL 校验，以及智能体提问和执行详情的查看方式。这些能力可以作为产品侧测试对象。数据库账号权限、查询超时、模型网络出口、日志归档、异常告警和恢复目标，则需要企业在自己的环境中配置并验收。私有部署改变运行边界，不自动完成上述工作。

PoC 结束时，把每项标成“通过、失败、未测”，留下证据位置和责任人。尤其是未测的入口、未接通的数据源和未验证的故障场景，不要在上线报告里写成已经安全。

参考资料

• •AskTable 如何工作
• •设置数据访问范围
• •日志与用户反馈
• •原 Article：安全 PoC 应验收哪十件事