这是一个示意性场景，而非客户案例。 它不使用任何真实组织、任何真实人员，也没有任何声称的结果。其目的是展示 Threada 可执行的 Vendor Security pack 如何将一次常规安全审查从请求一路承载到记录决策。下文描述的每个界面都是真实的产品能力；情景是为了说明而虚构的。
安全团队每周会出乎意料地花费大量时间处理那些大多属常规、偶尔严肃的审查。一个新的 SaaS 工具需要批准。一家供应商想要处理客户数据。有人针对一项现行政策请求例外。其中大多数都遵循已知的形式；少数则需要真正的审视。困难之处很少在于分析——而在于让每次审查保持一致、有据可依并留有记录。
下面是这项工作如何通过 Threada 的 Vendor Security pack 运行的。
工作的形态
Vendor Security 是一个带有 case 原型和三个已定义 intent 的 workspace pack：
- 供应商审查 — 依据政策评估新的或续约的供应商。
- 数据处理审查 — 评估供应商是否可以处理特定数据。
- 安全例外 — 处理偏离现行控制措施的请求。
审查人无需决定打开哪个表单。他陈述 intent，运行时便将其转化为安全队列上的结构化 WorkItem。
一次演示
设想一个请求到来：某个团队想要采用一家新的分析供应商，该供应商将接收产品使用数据。在此场景中，它通过一个已配置的受理渠道进入并成为一个 WorkItem。
Intent。 审查人（或请求者，通过某个渠道）描述他所需的结果——“审查这家分析供应商以获得数据处理批准。“运行时提取出供应商、所涉及的数据类别和一个初步的风险标记，并将其归档到 Vendor Security 队列。
Canvas。 WorkItem 在一个自适应 canvas 上打开。workspace 不会呈现空白表单，而是组装出此类审查所需的字段：数据类别、处理地点、子处理方、相关政策档案。在信息缺失之处，它正好就此发出提示，而不是呈现一份不加区分的问卷。
证据。 证据抽屉保存着评估所依据的内容——供应商提交的文档、对同一供应商的既往审查，以及对适用政策的引用。如果系统无法为某个特定主张提供依据，它会记录一个回退理由，而不是声称它并不具备的可信度。审查人一眼便能看出每个来源有多新。
控制。 审查在此处变为决策。批准一家新供应商的数据处理是一项有重大后果的 action，因此它会经过受治理的控制界面：一份提案，然后是针对当前活跃政策版本的明确批准。如果政策要求此数据类别需要第二位批准人，门控会强制执行。没有任何东西会悄然执行。
运行日志。 每一步都累积在运行日志上——受理、缺失信息的提示、查阅过的证据、批准及其给出者，以及最终记录的结果。由于 AI 参与者的 action 以独立的参与者事件形式出现，日志清楚地显示哪些步骤由系统处理、哪些由人做出决定。
团队最终得到什么
最后，安全团队拥有三样原本必须手动整合的东西：
- 一次一致的审查。 相同的 intent 总是产生相同的 workspace 形态，因此审查不会在繁忙的一周与清闲的一周之间在严格程度上发生漂移。
- 一个有据可依的决策。 批准与具体证据和一个具名的政策版本绑定，而非依赖审查人的记忆。
- 一份凭据。 整个审查都留有记录——在审计员面前可以辩护，并对下一位接手类似案件的审查人清晰可读。
常规审查推进得很快，因为 workspace 完成了组装。严肃的审查会得到充分的人工审视，因为控制界面坚持要这样。这种划分——将常规的自动化，把真正困难的案件交给人——正是全部要点所在。
我们为何将其作为场景发布
我们本可以把这包装成一个附带亮眼百分比的客户成功案例。我们不会这样做。在一位真实且知情同意的客户分享真实结果之前，我们在此印出的任何内容都是说明性的，而我们宁愿诚实地标注它，也不愿暗示我们并不拥有的证明。
真实存在的是这个 pack。Vendor Security 是一个可安装的工作流，运行在与其他每个 Threada pack 相同的受治理运行时之上，具备上述的各项 intent 和五个界面。如果你想看可执行的版本而非演示，pack 目录是开始的地方。