把安全做进推理运行时：LMSM如何用Linux的思路重构大模型护栏

大模型的安全护栏，正在遇到一个有点尴尬的问题：

安全技术越来越多，安全系统却不一定越来越好维护。

今天我们发现模型的某些内部特征可以识别危险行为，于是做一个基于 SAE 的护栏；

明天发现 Transcoder 效果更好，再接一套；

后天又训练出一个新的 Probe，于是再写一套判断逻辑、阈值管理和拒答代码。

久而久之，我们得到的可能不是一个越来越强的安全系统，而是一堆彼此独立的安全插件：

一个检测方法，配一套策略，再配一套执行逻辑。

来自新加坡国立大学、中国科学技术大学等机构的研究者提出了一个很有意思的反思：

安全检测方法为什么一定要自己负责“怎么拦”？

他们在论文《LMSM: LLM Security Framework Inspired by Linux Security Modules》中借鉴了 Linux Security Modules，也就是 Linux 安全模块的架构思想，提出了 LMSM（Language Model Security Modules）。

https://arxiv.org/html/2608.25697v1

它并没有发明一种新的越狱检测算法。

相反，它想解决一个更底层的问题：

能不能像 Linux 管理 SELinux、AppArmor 那样，为各种大模型内部安全检测能力提供一套统一的运行时安全框架？

在 LMSM 里，SAE、Transcoder、Probe 等技术都不再被视为完整的“安全护栏”。

它们只负责一件事：

提供安全证据。

至于这些证据意味着什么、应该采取什么策略，以及最终能不能把模型生成的内容交给用户，则交给另外的组件完成。

这听起来只是一次架构重构。

但它背后实际上代表着一种非常重要的安全思路变化：

未来真正稳定的，不应该是某一种检测算法，而应该是那条“安全决策必须经过统一执行”的路径。

今天的大模型护栏，为什么越来越像“外挂”？

现在的大模型安全大体存在几层防御。

第一层是模型本身的安全对齐。

例如通过 RLHF、DPO、安全微调等方式，让模型默认不去回答一些危险请求。

第二层是上下文控制。

例如系统提示词、指令层级以及各种 Prompt 防御。

第三层则是最常见的外挂护栏：

用户输入 ↓输入检测 ↓大模型 ↓输出检测 ↓用户

这些方式都有自己的价值。

但它们有一个共同特点：

大多数安全控制发生在模型外面。

输入检测器看到的是用户输入的文字；

输出检测器看到的是模型最终生成的文字。

它们通常并不知道：

模型在生成这些文字的时候，内部到底发生了什么。

但近年来，大量可解释性研究开始发现：

模型内部的激活状态本身也包含非常丰富的信息。

比如某些内部特征可能和拒答、安全风险、欺骗行为或者某种特定语义高度相关。

于是研究者开始尝试利用：

• 稀疏自编码器 SAE；

• Transcoder；

• 线性 Probe；

• 激活方向；

• Circuit；

• 各类隐藏状态监控器；

直接观察模型内部。

这相当于从：

“模型说了什么？”

进一步深入到了：

“模型现在正在想什么、计算什么？”

理论上，这当然可以带来更早的安全判断。

问题也随之出现。

今天的大多数模型内部安全方案，往往长这样：

SAE ↓特征选择 ↓阈值判断 ↓安全策略 ↓阻断代码

如果换成 Probe：

Probe ↓分类结果 ↓阈值判断 ↓安全策略 ↓阻断代码

换一个安全方法，后面的很多东西都要重新做。

于是一个新的安全算法，往往意味着：

重新造一个护栏。

论文认为，这其实不是算法问题，而是架构问题。

为什么会想到 Linux？

理解 LMSM，首先要理解一个看似与大模型没有关系的东西：

Linux Security Modules，简称 LSM。

Linux 里有很多不同的安全体系。

比如大家比较熟悉的：

SELinux、AppArmor。

不同企业、不同系统可能采用完全不同的访问控制策略。

但 Linux 并没有要求每一种安全方案都自己修改一遍内核。

它采用了一种非常重要的架构：

Linux 内核掌握最终执行权，安全模块负责提供安全判断。

比如一个程序准备读取某个敏感文件。

大致可以理解成：

应用程序 ↓申请读取文件 ↓Linux 内核 ↓安全检查点 ↓SELinux / AppArmor ↓允许 or 拒绝 ↓Linux 内核真正执行

这里最重要的一点，并不是 SELinux 有多强。

而是：

SELinux 本身并没有绕开内核，直接掌控文件系统。

真正能够决定：

打开文件拒绝访问

的是内核。

安全模块只是告诉内核：

根据我的安全策略，这一次操作应该允许或者拒绝。

这使得 Linux 可以把两件事情分开：

安全策略可以不断变化，但执行安全策略的路径保持稳定。

SELinux 可以升级。

AppArmor 可以修改。

甚至可以出现新的安全模块。

但是：

安全检查↓安全决策↓内核执行

这条链路不需要推倒重来。

LMSM 想做的，就是把这种思想搬进大模型推理系统。

在 LMSM 里，模型推理引擎开始扮演“内核”的角色

当然，大模型推理系统并不是真的操作系统内核。

论文也专门强调：

LMSM 只是借用了 LSM 的职责分离思想，并不继承 Linux Kernel 的隔离性和抗篡改能力。

但两者在架构上确实可以形成一组很直观的对应关系：

所以 LMSM 真正重构的，其实不是检测器。

而是整个：

证据 → 决策 → 执行

过程。

在 LMSM 中，大概变成：

模型隐藏状态 ↓安全 Backend ↓产生安全证据 ↓Policy ↓根据规则作出判断 ↓Enforcement Gate ↓允许 / 终止 / 拒答 ↓用户

其中最关键的一条原则是：

只有 Enforcement Gate，也就是“执行门”，有权真正改变推理状态或者释放输出。

SAE 没有这个权限。

Probe 没有。

安全规则也没有。

甚至做出安全决策的 Policy Evaluator，都不能直接终止模型生成。

它只能返回：

allowterminaterefuse

最后由统一的 Enforcement Gate 真正执行。

这其实就是整篇论文最核心的设计。

安全检测和安全执行，本来就是两件不同的事情

论文里还有一个非常重要的概念：

Mediation Correctness 和 Policy Effectiveness 必须分开。

翻译得简单一点就是：

“安全执行机制有没有正确工作”，和“你的安全规则到底准不准”，是两个问题。

举一个最简单的例子。

假设我们做了一个风险分类器：

风险分 > 0.7→ REJECT

这里至少存在两个完全不同的问题。

第一个问题是：

分类器判断 REJECT 以后，系统到底有没有真的拦下来？

这是执行正确性。

第二个问题则是：

0.7 这个阈值到底合不合理？分类器会不会误判？

这是策略有效性。

一个安全系统完全可能：

执行机制 100% 正确

但：

检测器准确率很差

那么系统仍然不安全。

反过来也一样。

检测算法可能非常优秀，但如果真正部署进 vLLM 后，因为并发调度、状态错位或者输出已经提前发给用户，导致安全规则没有正确执行，那么再好的检测算法也没有意义。

所以在 LMSM 看来：

安全检测 ≠ 安全策略 ≠ 安全执行

三者必须分别设计。

这个观点非常重要。

因为今天很多大模型安全研究会报告：

ASR 从 40% 降到了 5%。

然后把它称为一个安全系统。

但从系统安全视角看，还应该继续追问：

这条安全规则到底在哪里执行？

谁拥有最终阻断权限？

多请求并发时安全状态会不会串？

检测器升级以后是不是还得重写推理服务？

这些问题，正是 LMSM 真正关心的。

SAE、Probe、Transcoder，从“护栏”降级成“传感器”

LMSM 设计里一个非常漂亮的地方，是它对模型内部安全方法进行了重新定位。

过去我们可能会说：

“用 SAE 做一个护栏。”

LMSM 则认为：

SAE 本身不是护栏。

它只是一种产生安全证据的方法。

Probe 也是。

Transcoder 也是。

在 LMSM 里，这些东西统一被称为：

Security Backend。

也可以简单理解成：

安全传感器。

它们从模型某个内部位置读取隐藏状态：

模型隐藏状态H

然后转换成一组标准化的安全信号：

Evidence 1Evidence 2Evidence 3……Evidence K

至于这些 Evidence 到底是怎么计算出来的，Policy 并不关心。

它可能来自：

SAE Feature

也可能来自：

Transcoder Feature

还可能只是一个普通线性分类器的：

Probe Margin

LMSM 只要求：

最后按照统一接口，把安全证据交出来。

这就带来了一个很重要的变化：

过去：

SAE→ SAE专用策略→ SAE专用执行代码

LMSM：

SAE ─────┐Transcoder ─┼→ Evidence → Policy → EnforcementProbe ────┘

这样一来，未来如果新的模型解释技术出现：

Circuit新的 Probe新的激活分析方法

理论上都不需要重新写整套护栏。

只需要实现：

Backend Adapter。

也就是把新的模型内部信号转换成 LMSM 能理解的安全证据。

这其实非常像操作系统里的：

驱动和统一接口。

真正稳定的应该是“Target”，而不是检测模型

LMSM 还有一个非常值得产品设计借鉴的概念：

Target。

Target 描述的不是：

“我要检测 SAE Feature 521。”

而是：

“我的系统不允许出现什么行为。”

比如一个医疗应用可能规定：

禁止向具体患者直接提供特定药物剂量建议。

这就是一个 Target。

它代表的是：

业务安全目标。

今天，这个 Target 可能通过 SAE 识别。

明天发现 SAE 不好用，可以换成 Probe。

未来出现更好的 Transcoder，也可以继续换。

但是：

“禁止针对患者提供具体剂量建议”

这条安全目标本身不用变。

于是系统形成了几个非常清楚的层次：

Target：业务到底要防什么 ↓Backend：系统怎么观察风险 ↓Rule：什么条件算触发风险 ↓Policy：当前部署启用哪些规则 ↓Enforcement：触发以后真正采取什么动作

这其实是一种非常成熟的安全产品设计思路：

安全目标应该独立于安全检测技术存在。

否则每次算法升级，业务策略都跟着重做，最后整个系统会高度耦合。

一个很现实的问题：Batch 会动

论文真正让我觉得比较扎实的地方，是它没有只停留在概念图。

作者把 LMSM 接进了 vLLM。

而这立刻带来一个非常现实的问题：

Continuous Batching。

大模型推理服务为了提高 GPU 利用率，会不断动态调整 Batch。

假设某一时刻：

Row 0 → Request ARow 1 → Request BRow 2 → Request C

一会儿 B 生成完了。

新的请求进来以后，Batch 可能重新排列：

Row 0 → Request CRow 1 → Request DRow 2 → Request A

这意味着：

Batch 里的第几行，并不代表某一个固定用户请求。

如果你的安全系统错误地把状态记录成：

risk_state[row_id]

就可能出现一个严重问题：Request A 的安全状态，被错误地继承给了 Request D。

这对于普通推理 Bug 来说已经很麻烦，对于安全系统来说则更加危险。

因为结果可能是：

A 的风险状态↓污染 B

或者

A 的风险状态↓在调度后直接丢失

所以 LMSM 强制使用：

Request-Keyed State。

也就是说：

state[request_id]

而不是：

state[batch_row]

无论 Scheduler 怎么重新排列 Batch，安全状态始终跟着 Request ID 走。

作者还专门做了 Scheduler Churn 压力测试。

在 64 个请求中经历：

• 32 次 Slot 重用；

• 23 次 Row 移动；

32 对重复请求的：

• 最终动作；

• 安全类别；

• 触发步骤；

• 各规则阈值触发结果；

全部保持一致。

24 个需要终止的请求可以被单独停止，同时其余 40 个请求继续运行。

这个实验看起来没有 ASR 那么吸引眼球。

但从真正的安全基础设施角度，它反而非常重要。

因为它证明：

这套架构开始考虑真实推理服务里的并发、调度和状态隔离问题了。

真正的安全边界，是“内容有没有释放”

LMSM 还有一个很重要的安全设计：

Buffered Output，也就是输出缓冲。

普通流式 Chatbot 通常是：

生成 Token 1↓立即发给用户生成 Token 2↓继续发给用户

但这会产生一个很现实的问题。

假设模型生成到第 64 个 Token 时，安全系统才确认：

这条回答应该被阻断。

可是前面 63 个 Token 已经发出去了。

这时候再拒答，实际上已经发生了信息泄露。

所以 LMSM 把真正受保护的操作定义成：

External Output Release——对外释放结果。

模型可以在内部产生：

Token 1Token 2……Token 64

但这些 Token 暂时只存在推理系统内部。

流程变成：

模型生成 ↓Buffer ↓安全判断 ↓Enforcement Gate ↓允许 ↓对外释放

如果安全规则最终判断：

REFUSE

那么此前模型内部生成的内容可以全部丢弃。

用户最终只会看到固定的拒答回复。

这就把安全边界从：

“模型有没有产生危险内容”

重新定义成：

“系统有没有把未经授权的内容交给外界”。

这个思想其实非常接近传统系统安全里的 Reference Monitor。

内部状态可以非常复杂。

但所有真正影响外部世界的关键操作，都必须经过一个可信的中介。

越早检查，代价也越高

既然安全系统可以观察每一步生成，那么一个自然的问题就是：

到底什么时候检查？

论文测试了两种方式。

第一种叫：LMSM-Checkpoint。

可以理解成：

生成↓生成↓……↓第64个Token↓统一检查

它只在一个固定时间点做判断。

第二种则叫：LMSM-Anytime。

流程变成：

Token 1 → 检查Token 2 → 检查Token 3 → 检查……

一旦风险信号第一次超过阈值，就立刻介入。

从安全响应速度来看，Anytime 显然更积极。

在论文专门设计的一组 WildJailbreak 时序实验中：

Checkpoint 固定在：

Token 64

进行判断。

而 Anytime 第一次触发干预的中位位置只有：

Token 15。

对于发生干预的请求，Anytime 相比 Checkpoint，中位数可以多避免大约 48 个后续 Token 的生成。

但世界上没有免费的安全能力。

检查得越频繁，计算成本也越高。

这就出现了一组非常典型的系统工程权衡：

更早发现风险 ↑安全响应更快 ↑计算成本也更高

实验结果

论文的主要实验使用：Qwen3-4B，并开启 Thinking，推理环境是vLLM V1 + 单张 NVIDIA H100，最多运行32 个并发序列。

安全测试包括：

• HarmBench：602 条；

• WildJailbreak：2000 条危险样本；

• XSTest：250 条安全样本。

其中有一组非常关键的 baseline：

Matched Disabled。

它并不是简单的“裸 Qwen”。

安全 Backend、Evidence 计算、规则判断这些路径全部还在运行。

唯一的区别是：

最终不真正执行阻断动作。

这样就能比较干净地观察：

真正开启 Enforcement 以后，到底发生了什么。

结果非常明显。

HarmBench

• Matched Disabled：39.20%

• LMSM-Checkpoint：3.32%

• LMSM-Anytime：6.81%

WildJailbreak

• Matched Disabled：41.90%

• LMSM-Checkpoint：7.35%

• LMSM-Anytime：6.00%

也就是说，在两个危险测试集上，危险输出率相对下降了：

82.5%～91.5%。

而且这种效果并不是简单靠“什么都拒绝”换来的。

XSTest 上的误拒率：

• Matched Disabled：2.40%

• Checkpoint：4.40%

• Anytime：5.60%。

虽然误拒有所增加，但并没有因为加了安全模块而直接变成一个极度保守的模型。

Checkpoint 的工程代价并不算高

更加值得注意的是吞吐量。

在 32 并发序列下：

LMSM-Checkpoint 仍然可以保留 baseline 98.14%的吞吐量。

也就是说，吞吐损失大约只有：1.86%。

相比之下，LMSM-Anytime 因为每一个 Decode Step 都需要更新和判断安全证据，只保留83.91%的吞吐量。

大约意味着 16.09% 的性能损失。

这就形成了一个很容易理解的选择。

Checkpoint 更像：

每隔一段时间过一次安检。

Anytime 则像：

整个过程一直有人盯着。

后者反应更快，但自然更贵。

更有意思的是，作者又把 Checkpoint 的规则数量从：

1↓6↓15

逐渐增加。

15 条规则全部开启时，系统依然保留了 baseline 96.89% 的吞吐量。

一个重要原因在于这些规则并不会各自重新跑一遍模型。

而是：

一次模型 Forward ↓一次 Backend 计算 ↓共享 Evidence ↓多个安全 Rule

这也是统一安全运行时相比多个外挂护栏的另一个潜在优势。

论文真正想证明的，其实不是“Probe 比护栏更强”

如果只看论文中的：

HarmBench 从 39.20% 降到了 3.32%。

其实很容易误解这篇工作的价值。

因为这个数字并不是它最重要的贡献。

作者还分别尝试了 Gemma-3 + SAE 以及 Qwen3 + Transcoder。

在六类 HarmBench 测试上：

• Gemma-3 + SAE 从未保护状态下的 46.2%下降到六规则状态下4.2%。

• Qwen3 + Transcoder 则从48.1%下降到4.9%。

更关键的是：

作者直接在相同的 Qwen3 + vLLM 运行时里，把：

Dense Probe

替换成：

Transcoder

而 Request State、Policy、Action 和 Enforcement 这些外围机制不用重写。

这才是 LMSM 最想证明的事情：

安全检测能力可以换，但安全运行时不需要跟着推倒重来。

今天是 Probe。

明天可以是 SAE。

后天也许是新的 Circuit Monitor。

真正需要稳定下来的应该是：

Request ↓Evidence ↓Policy ↓Decision ↓Enforcement ↓Output Release

这条安全路径。

从“外挂护栏”到“安全基础设施”

这也是我认为 LMSM 最重要的地方。

大模型安全过去很长时间都围绕一个问题：

怎么让模型本身变得更安全？

所以我们不断改模型：

安全微调RLHFDPO拒答训练安全对齐

后来大家逐渐发现：

模型本身很难覆盖所有安全需求。

于是又开始增加：

Input GuardOutput GuardPrompt GuardTool Guard

现在 LMSM 又往前走了一步：

既然模型不可能永远安全，检测算法也会不断变化，那么能不能把“安全执行”本身做成推理基础设施？

这和传统安全系统的发展路径其实非常相似。

杀毒软件不会要求每个应用自己实现进程隔离。

SELinux 也不会要求每个程序自己决定有没有文件权限。

成熟的安全系统最终都会形成：

稳定的安全控制面。

而具体：

检测什么怎么检测什么阈值启用什么策略

则可以持续变化。

如果沿着这个方向继续发展，大模型系统未来可能会形成类似：

应用层────────────────Agent / Chat / RAG安全策略层────────────────Policy安全感知层────────────────SAE / Probe / Transcoder / Guard推理运行时────────────────vLLM / SGLang / TensorRT-LLM安全执行层────────────────Enforcement / Output Release基础设施────────────────GPU

这时候安全就不再是：

在大模型 API 前后各挂一个分类器。

而开始真正进入：

AI Infra。

一个很大的现实问题：Streaming

看到这里，很容易觉得 LMSM 已经是一套非常完整的安全架构。

其实还远没有。

它当前最明显的问题，就是前面提到的：

Buffered Output。

LMSM 的安全保证依赖一个重要前提：

模型生成的结果在安全判断完成以前，不会被直接释放给用户。

但是今天大量 Chatbot 都采用：

流式输出。

也就是：

Token 1 → 用户Token 2 → 用户Token 3 → 用户……

如果系统到了第 64 个 Token 才判断：

这条回答应该 REJECT。

前面的内容已经无法收回。

论文也明确承认：

当前的安全目标并不覆盖任意形式的 Token Streaming。

因此 LMSM 更天然适合：

• Agent 内部调用；

• 后台任务；

• Batch Generation；

• 高安全业务；

• 允许短暂缓冲的生成服务。

如果未来真正用于实时 Chat，则需要继续解决：

Chunk Buffer滑动窗口释放分段授权推测式安全检查

之类的问题。

这很可能也是类似运行时安全框架真正进入生产系统时必须突破的一关。

运行时是可信的，但“安全传感器”仍然可能被骗

LMSM 还非常明确地区分了另外一个问题。

即使：

Evidence↓Policy↓Enforcement

整个执行过程完全正确，

也不代表安全检测一定不会被绕过。

比如攻击者有可能构造一种输入：

模型最终仍然输出危险内容

但：

内部激活看起来并不像危险行为

这类针对隐藏空间监控器的攻击已经被其他研究证明存在。

换句话说：

SAE 可能被骗。

Probe 也可能被骗。

Transcoder 也不天然安全。

论文并没有试图回避这个问题。

相反，它明确把：

Mediation Correctness

和：

Backend Robustness

分开。

也就是说：

LMSM 可以保证“一旦安全规则决定拒绝，系统真的会拒绝”。

但它不能保证：

“安全规则永远能够发现所有危险行为”。

这其实是一个非常重要的边界。

现在的 LMSM，还称不上“大模型安全内核”

除此之外，这项工作目前还有不少现实限制。

例如论文实验主要运行在：

单张 H100、Eager vLLM。

还没有证明：

大规模多机部署各种推理框架复杂生产环境

中的效果。

当前一个 Policy 也只支持：

一个 active backend binding 和一个 activation site。

但未来真正的安全系统很可能需要：

Layer 8 Probe+Layer 24 Transcoder+Residual Stream SAE+Output Guard

甚至来自多个模型层、多个 Backend 的 Evidence Fusion。

论文也承认，未来可以沿着现有接口扩展到多个 Backend，并进一步支持：

内容脱敏重新生成人工审核二次模型检查

等动作。

当前版本只有：

ALLOWTERMINATEREFUSE

三种主要处置。

所以把 LMSM 直接称为：

“大模型安全内核”

可能仍然有些过早。

但它已经开始提出：

大模型安全运行时应该长什么样。

真正值得关注的，是安全研究正在进入 Runtime

如果把最近一些大模型安全研究连起来看，会发现一个很明显的变化。

过去研究者更多讨论：

Prompt↓Model↓Output

如何让这个模型更加安全。

但随着 Agent、工具调用、RAG 和长程任务逐渐普及，整个系统已经变成：

Context↓Model↓Runtime↓Tool↓Environment↓Memory↓下一轮 Model

这时候：

模型已经不再是整个安全系统。

运行时开始成为越来越重要的安全边界。

这也是为什么我们最近会不断看到：

Agent Runtime Governance安全协处理器Tool PermissionHarness SecurityReference MonitorRuntime Policy

这些原本更加接近操作系统、云安全和基础设施安全的概念，开始进入 AI 安全。

LMSM 就位于这条趋势线上。

它并没有提出一种万能检测算法。

但它提出了一个可能更加长期的问题：

当未来的安全检测技术一年换好几代时，我们究竟应该把什么东西稳定下来？

LMSM 给出的答案是：

把安全执行路径稳定下来。

未来的大模型护栏，也许会越来越像操作系统安全

Linux 安全体系真正成熟的地方，从来都不是：

Linux 找到了一个永远不会误判的检测算法。

而是它建立了一套清楚的权限边界：

谁提出请求。

谁提供安全策略。

谁拥有执行权限。

哪些操作必须经过检查。

以及最终谁能够真正改变系统状态。

LMSM 正试图把这种思想带进大模型。

在这个框架里：

• SAE 可以升级。

• Probe 可以替换。

• 规则可以变化。

• 阈值可以重新校准。

• 业务安全目标也可以不断增加。

但是有一件事不应该跟着变化：

任何未经安全策略授权的模型输出，都不能绕过统一的执行路径直接进入外部世界。

这可能才是 LMSM 最值得关注的地方。

它把大模型安全讨论，从：

“怎么造一个更强的检测器？”

推进到了：

“我们应该怎样设计一个真正能够承载这些检测器的安全系统？”

而这两个问题，其实完全不是一个层级。

写在最后

今天我们讨论大模型安全时，经常会把注意力放在：

• 哪个模型更安全

• 哪个 Guard 模型准确率更高

• 哪个 SAE Feature 能找到危险行为

• 哪个 Probe 能把 ASR 再降几个百分点。

这些当然都重要。

但 LMSM 提醒了另一个容易被忽略的问题：

发现危险，只是安全系统的一半。

剩下的一半是：

谁负责做决定？

谁拥有真正的执行权限？

检测方法变化以后，安全执行链路是否仍然可靠？

并发调度以后，不同用户的安全状态会不会串？

在内容真正释放给用户以前，系统是否还有最后一次阻止它的机会？

这些问题，已经不再属于单纯的“模型安全”。

它们属于：

AI 系统安全。

而当大模型逐渐变成整个软件系统中的基础设施之后，这种变化也许不可避免。

未来最好的安全技术可能一直在变化。

但真正成熟的系统，不能每出现一种新的安全技术，就重新造一遍护栏。

检测器可以不断换，策略可以不断改，但决定“模型输出能不能真正离开系统”的那扇门，应该始终掌握在一个稳定、可审计的安全运行时手里。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。