Authorization
此活动是否已获授权？
SOC 上报的大部分内容并非恶意。它们往往是真实的人员或系统在做真实的工作，只是碰巧看起来像攻击：管理员在凌晨 3 点使用紧急破窗账户、部署流水线改动了某个配置文件、扫描器在获批渗透测试期间对某个子网进行扫描。一个告警是否为良性，往往不取决于告警本身，而取决于其周边组织的状态。两个字节级完全相同的告警，仅仅因为是否有变更工单、维护窗口或已批准的基线覆盖该活动，就可能得出完全相反的处置结论。
Authorization 是为 SocTalk 提供这种组织状态上下文的一层。它将带类型的记录（变更工单、常设基线、变更冻结、禁令，以及关于资产和账户的实体事实）绑定到告警中的活动上，并推断是否存在单条记录能够完整覆盖它。它只会通过找到覆盖性证据来降低可疑度。它从不提升可疑度，也从不覆盖恶意信号。
它并不是硬塞进分诊流程的一个独立步骤。它是智能体循环在调查过程中收集的上下文，并会解析为三种状态之一，从而影响裁决。下游的一切仍会经过安全底线，而 authorization 永远无法削弱这条底线。
已覆盖、被反驳、缺失
每个告警的 authorization 都会解析为以下三种状态之一，而后两种状态之间的区别正是全部关键所在：
- 已覆盖（Covered）。 存在单条记录完整覆盖了该活动：正确的主体、目标、动作、时间窗口、日历有效性和审批。可疑度被降低。
- 被反驳（Contradicted）。 存有记录，但没有任何一条覆盖该活动，或存在一条高优先级禁令禁止该动作。变更工单存在，但已过期，或对应的是另一台主机，或它所需的变更冻结从未被豁免。这是一项发现，而非缺失，会上报给人工处理。
- 缺失（Absent）。 完全没有相应类型的记录在案。缺失绝不会被视为已授权。SocTalk 会请求更多信息，而不是假定该活动已获批准。
区分「缺失」与「被反驳」至关重要。一份过期或错误的工单绝不能被解读为「接近已授权」。它恰恰相反：本应覆盖此活动的书面材料并未覆盖它，而这一点值得人工关注。
authorization 事实的来源
事实通过三种途径进入存储，信任度依次递增：
- 租户对自身环境断言事实。 客户从 Authorization 区域声明一个维护窗口或一条常设基线。租户断言的事实以待处理状态落地，在 MSSP 分析师批准之前不会影响分诊。
- 系统通过 ingest API 推送事实。 预置脚本、CI 钩子和连接器使用按租户凭据提交带类型的事实。信任度由凭据打上，绝不取自载荷，因为任何能推送事实的人都能压制一次检测。
- 分析师回答 authorization 问题。 当分诊恰因 authorization 缺失而陷入停滞时，分析师回答一次，该答案便成为一条可复用的记录。这就是下文的流程。
从控制台记录一条事实：一个实操示例
事实不必来自连接器或一次调查。MSSP 分析师或租户管理员可以直接记录一条，而控制台表单是围绕事实模型构建的，因此你唯一能提交的就是一条有效的事实。
以一个常见情形为例。Acme 的 svc-deploy 服务账户将在周五的维护期间在 db-01 上运行特权命令，该操作已在变更工单 CHG-1001 下获批。若不加说明，这些命令触发的 sudo 看起来正是 SOC 会上报的那类特权使用。将该变更工单记录为一条授予，正是告诉 SocTalk 此活动已被覆盖的方式。
打开 Authorization 区域。在 MSSP 一侧，先从租户切换器中选择客户；租户管理员则直接看到自己的组织。该列表以通俗易懂的摘要展示每一条在案事实，及其来源与信任层级、有效性和审查状态。
选择 New fact 打开引导式编辑器。你先选择种类（授予、禁令、变更冻结或实体上下文）和轨道（account，用于以主体、目标和动作描述的主机活动；或 FIM，用于以路径和变更类型描述的文件变更）。随后表单只显示对该组合合法的字段，因此你无法构建一条引擎会拒绝的事实：变更工单授予需要一个结束日期，FIM 禁令不能携带账户动作，账户冻结按环境而非按配置类别限定范围。一行 Reads as 会在你输入时以通俗英文重述该事实，而来源和信任层级会被自动打上，而非手工输入。
对于该维护情形：种类 Grant、轨道 Account、主体 svc-deploy、目标 db-01、动作 sudo-exec、授予类别 Change ticket、引用 CHG-1001、有效期至窗口结束。Create fact 会将其写入，它便以分析师断言的信任度出现在列表中。从那时起直到有效期届满，针对该账户、动作和主机的告警都会解析为已覆盖，其可疑度随之下降；有效期届满后，同一告警再次变为缺失，SocTalk 也回到询问而非假定的状态。
租户管理员以同样的方式记录事实，只有一点不同：租户断言以最低信任层级落地为**待审查（awaiting review）**状态，在 MSSP 分析师从这同一个列表（上方的待处理行）批准它之前，不会影响分诊。倾向于批量作业、或以自动化方式驱动存储的分析师，可以将编辑器切换到 Advanced: edit JSON 并提交原始事实；两种方式适用相同的校验。
回答一个 authorization 问题
当一次调查因 authorization 缺失而无法定论，且不存在恶意信号时，审查会携带一个带类型的 authorization 问题，而非笼统的补充信息请求。分析师被询问的只有一件事：此活动是否已获授权？
该面板陈述所涉的确切活动，并提供一个单独的操作，区别于批准或拒绝。如果该活动确已获授权，分析师会设置该授权应保持有效的时长，并选择 Confirm authorized, save reusable authorization。这将写入一条持久的、由分析师断言的授予，其范围精确限定为该活动（此账户、此动作、此主机），并带有所选的有效期。
被保存的授予正是关键所在。下次同一活动再产生告警时，已有一条记录覆盖它，因此不会再次提出该问题。问一次，记住它。该授权的范围精确限定为该活动并带有有效期，因此它不会悄然扩大，也不会永久存在；它会出现在 Authorization 区域，可随时被审查或撤销。
有一条规则是刻意为之：事实只能通过这一明确的回答来创建。SocTalk 绝不会从一次普通的关闭或拒绝中学到授权。分析师清空队列，与分析师声明某活动已获认可，并不是一回事；若将二者等同视之，队列压力便会悄悄污染存储。
Engagements
一个事实回答的是一个常设问题：此账户是否被允许在此主机上执行此操作。有些授权根本不是常设的，它们被限定在一个时间窗口内，在此期间原本可疑的活动是被预期的。一次获批的渗透测试、一次红队演练或一个维护窗口，都是一种会开启然后关闭的授权。SocTalk 将其建模为一个 engagement，而 engagement 本身就是一种授权：一个有范围、有时间边界的授权窗口，在此窗口内它所描述的活动是被预期的，而非告警性的。
engagement 与事实一同存放在同一个租户 Authorization 区域中，位于它们各自的 Engagements 选项卡下。较早的 /engagements 路径仍然有效，并会深度链接直达该选项卡，因为 engagement 已被并入统一的 Authorization 区域，而非作为一个独立界面保留。声明一个 engagement 是一个结构化表单：一个名称和种类、窗口的起止时间，以及它所覆盖的范围，即经验证的源 IP、范围内的主机和 ATT&CK 技术 ID。
不过，engagement 的工作方式与事实不同。它不设闸门：一个获得租户授权的用户可以直接声明它，也可以直接撤销它，无需 MSSP 审查步骤。engagement 所做的是按经验证的源、目标和时间窗口对活动进行去冲突（deconflict）。落在一个已声明 engagement 范围内的告警活动，即在窗口期内由一个范围内的源对一个范围内的目标执行的活动，会被归因于测试人员：SocTalk 记录该观测，将该告警移出开放队列，并跳过对它的 LLM 分诊。它绝不会被自动关闭或标记为误报，该观测行仍可查询并被计入统计。测试人员落在已声明范围之外的活动则会被标记以供进一步查看，而非直接放行。当窗口关闭时，去冲突不再适用，该活动会重新按常规分诊。
护栏
authorization 是一个压制面，因此其边界是在代码中强制执行的，而非交由提示词措辞决定：
- 缺失绝不自动关闭。 没有覆盖性记录就意味着由人工决定，绝不会自动关闭。
- authorization 绝不覆盖恶意信号。 一条已保存的「已授权」事实无法关闭一个同时携带 IOC 命中、恶意富化或活动事件关联的告警。关联先于压制运行，而安全底线会独立于任何事实否决这些情形。可复用的 authorization 会降低常规可疑度；它不会让系统对复用同一活动的真实攻击视而不见。
- 记忆是带类型且受治理的。 事实携带来源、信任层级、范围和有效期。它们绝非自由格式的提示词记忆，且宽泛或特权的事实理应经过审查。
- 信任是分层的。 连接器验证的记录高于系统断言的记录，后者高于分析师断言的记录，再高于常规遥测，而常规遥测高于租户断言的记录。信任度更高的记录可佐证或覆盖信任度更低的记录。
它出现在哪里
authorization 上下文会被渲染进 AI 对每一次携带它的调查的推理中，因此模型会亲自权衡覆盖性证据，而不是被直接递上一个是或否。已保存的事实、其审查状态及有效期会列在 UI 的 Authorization 区域，分析师可在此撤销任何事实。关于谁可以断言、审查和回答，参见 用户与角色；关于 authorization 问题所依托的审查队列，参见 人工审查。