Agent Supply Chain Security：MCP、Skills 与 AI Agent 软件供应链安全新边界 | 木卫四科技

wangwalfred

13人浏览 · 2026-09-05 17:33:49

wangwalfred · 2026-09-05 17:33:49 发布

从 AIR 5000 万美元融资、Postmark MCP 事件到 Tool Poisoning，为什么 Agent Supply Chain Security 正在成为 AI 安全的新边界

从 AIR 5000 万美元融资、Postmark MCP 事件到 Tool Poisoning，Agent 的安全问题正在从“模型说了什么”，进一步走向“Agent 信任了什么、调用了什么，以及最终做了什么”。

2026 年 9 月 1 日，AI Agent 安全公司 AIR Security 宣布走出隐身模式。TechCrunch 报道称，这家公司已经完成两轮合计 5000 万美元的种子融资，产品聚焦一个正在快速出现的新问题：企业 Agent 正在持续加载和调用 Skills、Plugins、MCP Servers、Tools、Sub-agents 等外部能力，而这些“Agent Add-ons”本身也需要像软件依赖一样被发现、审核、持续验证和撤销。

这件事值得关注，并不只是因为一笔融资。

它释放出的更重要信号是：当 AI Agent 从“回答问题的软件”变成“能够连接工具、系统甚至现实设备的执行主体”之后，软件供应链安全正在进入一个新的阶段。

过去我们关心的是代码包有没有漏洞、依赖有没有被篡改、构建过程是否可信；接下来还需要继续回答：

这个 Agent 安装的 Skill 是谁发布的？
连接的 MCP Server 是否可信？
Tool Description 有没有被投毒？
新版本是否偷偷扩大了权限？
Sub-agent 是否把能力继续委托给了另一个 Agent？
当一个组件在运行时发生漂移，系统能否在真实动作发生前撤销它？

这就是正在形成的 Agent Supply Chain Security——Agent 软件供应链安全。
在这里插入图片描述

一、什么是 Agent 软件供应链安全？

什么是 Agent Supply Chain Security？

Agent 软件供应链安全（Agent Supply Chain Security），是针对 AI Agent 所加载、安装、发现、委托或调用的外部能力组件建立可信控制链的安全体系。

它覆盖的对象不再只是传统代码依赖，还包括：

Skill → Plugin → MCP Server → Tool → Connector → Sub-agent → A2A Agent → External Context

其目标是保证这些组件：

来源可信、版本可验证、能力可解释、权限最小化、运行时行为可持续验证，并且在风险发生后能够被快速隔离和撤销。

传统软件供应链更关注：

Source Code → Package → Dependency → Build Artifact

Agent 时代则进一步扩展为：

Publisher → Agent Add-on → Capability → Permission → Context → Delegation → Runtime Behavior → Real-world Action

这里最重要的变化不是“软件包变多了”，而是：

Agent 的外部组件开始直接参与模型决策，并可能通过 Agent 获得真实行动权。

这意味着，一段 Tool Description、一份 Skill Instruction、一个 MCP Server 返回的上下文，甚至另一个 Sub-agent 的回复，都可能成为后续动作的一部分。

下面是传统软件供应链与 Agent 供应链的对比：

二、为什么这个问题会在 2026 年快速浮出水面？

1. Agent 的“能力安装”正在平台化

Agent 正在经历类似移动 App、浏览器插件和开源包管理器曾经经历过的过程：第三方能力开始被标准化封装、集中发现、一键安装、自动更新和规模化分发。

目前已经可以看到多个明显信号：

MCP Registry 已进入 Preview，为公共 MCP Server 提供集中元数据、命名空间、版本与发布机制；
Agent Skills 已形成开放规范，Skill 可以包含 SKILL.md、脚本、参考资料和资源文件；
OpenAI Codex / ChatGPT 等 Agent 产品正在把 Skills、Apps、插件能力纳入工作流；
A2A（Agent2Agent） 正在推动 Agent-to-Agent 的发现、身份和动态委托标准化，并于 2026 年 8 月加入 Agentic AI Foundation；
Microsoft、AWS、Cloudflare、Alibaba Cloud、Tencent Cloud 等平台都在增加 Agent Registry、MCP Gateway、Agent Identity、Tool Governance、Private Marketplace 等能力。

当“能力安装”形成生态以后，安全问题自然会从单个 Tool 的权限控制，扩展到完整的供应链治理。

2. Registry 解决“它是谁”，但不自动等于“它可信”

Registry 很重要。

它可以帮助企业确认 Publisher、Namespace、版本、来源仓库和发布状态，也可以配合 Hash、签名、OIDC、SBOM 等传统软件供应链机制，提高组件来源和完整性的可信度。

但 Registry 无法单独回答几个更困难的问题：

Tool Description 是否藏有恶意指令？
一个合法的新版本是否扩大了访问范围？
MCP Server 的 URL 没变，但后端行为是否已经变化？
Skill 新增脚本后是否开始访问网络或文件系统？
一个 Agent 是否把高权限能力继续委托给了低可信 Sub-agent？
组件原本没有问题，但外部威胁情报是否已经表明 Publisher、Domain 或 Dependency 出现风险？

因此：

Registry 是 Agent 供应链安全的基础设施，但不是完整的 Trust System。

三、Agent 供应链攻击已经不只是理论风险

1. Postmark MCP：真实的 Agent 工具供应链攻击

2025 年，安全研究人员发现 npm 包 postmark-mcp 冒充 Postmark 官方 MCP 集成。

该包在连续发布多个正常版本、建立一定信任之后，在后续版本中加入了秘密 BCC 邮件的恶意行为。Postmark 官方随后确认该软件包并非其官方发布，并确认恶意版本存在未经授权复制邮件内容的问题。

这个案例很典型，因为它同时具备传统软件供应链攻击与 Agent 工具生态的新特征：

品牌与 Publisher 冒充；
npm 等公共软件生态分发；
先正常、后恶意的 Rug Pull；
对 Agent 已获得的邮件能力进行滥用；
最终影响真实业务数据。

Agent Tool 已经具备“软件包 + 权限主体 + 决策上下文”的复合属性。

参考：

Koi Security: https://www.koi.ai/blog/postmark-mcp-npm-malicious-backdoor-email-theft
Postmark 官方说明: https://postmarkapp.com/blog/information-regarding-malicious-postmark-mcp-package

Postmark MCP 攻击的时间线如下：

2. Tool Poisoning：没有 CVE，也可能是不安全的 Tool

Invariant Labs 等安全研究已经展示了 MCP Tool Poisoning：

攻击者可以把恶意指令放进 Tool Description 等 Agent 可见、但用户未必直接看到的元数据中。当模型在规划过程中读取这些描述时，它可能把恶意内容当成合法工具说明的一部分，继而执行额外动作。

这类问题意味着：

“代码扫描通过、没有已知 CVE、Hash 没有变化”并不能证明一个 Agent Tool 是安全的。

因为对于 Agent 来说，语义本身也可能参与执行。

传统安全工具主要扫描代码和依赖，而 Agent 供应链还需要理解 Tool Description、Instruction、Input Schema、权限和真实调用上下文。

参考：

Invariant Labs: https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
OWASP MCP Tool Poisoning: https://owasp.org/www-community/attacks/MCP_Tool_Poisoning

Tool Poisoning 的攻击流程如下：

3. 从单一 Tool 到多 Tool、Sub-agent 和动态委托

Agent 系统正在从“一个模型调用几个固定 API”，演进为动态能力图：

Agent
 ├─ Skill A
 │   ├─ MCP Server A
 │   │   ├─ Tool 1
 │   │   └─ Tool 2
 │   └─ External Context
 ├─ Skill B
 └─ Sub-agent
     ├─ MCP Server B
     └─ Another Agent

这使新的风险开始出现：

Tool Shadowing；
多工具组合攻击；
权限通过 Sub-agent 继续传递；
动态 Delegation 导致原本清晰的信任边界变成运行时信任图；
组件更新后，能力和权限与审核时不再一致。

因此，Agent Supply Chain Security 最终保护的并不是一个 MCP Server，而是完整的 Agent Capability Graph。

四、为什么传统 SBOM、SCA 和签名还不够？

传统软件供应链方法依然非常重要，而且应该继续使用。

Agent 供应链并不是推翻 SBOM、SCA、SLSA、Sigstore、CVE，而是在这些机制之上补足新的安全维度。

传统机制	能解决什么	Agent 时代还缺什么
SBOM	软件组件清单	Skill、MCP、Tool、Sub-agent 与 Capability 清单
SCA	开源依赖和已知漏洞	Tool Description、Context、Permission、Behavior
Hash / Signing	完整性、Publisher 验证	合法版本的恶意语义和权限扩张
CVE / CWE / OSV	已知漏洞	无 CVE 的 Tool Poisoning、Prompt Injection
SLSA	构建与发布来源	运行时远程服务与行为漂移
IAM / ACL	谁原则上能访问什么	当前目标和状态下“这一次动作”是否应该发生

真正新增的六个维度包括：

Semantic Capability：这个组件到底能做什么？
Semantic Permission：它能读、写、删除、控制到什么程度？
Context Provenance：决策输入来自哪里，是否可信？
Dynamic Delegation：能力是否继续委托给其他 Agent？
Behavioral Drift：运行时行为是否和审核时一致？
Physical Side Effect：最终动作是否会影响真实世界？

因此，未来更合理的思路可能不是只有一个 SBOM，而是进一步建立：

Agent Add-on BOM + Capability BOM

也就是不仅知道“装了什么”，还要知道“它能做什么”。

五、为什么只有 Tool ACL 仍然不够？

Tool ACL 为什么不能解决 Agent 的全部安全问题？

Tool ACL 只能回答“某个 Agent 原则上有没有调用某个 Tool 的权限”，却无法完整回答“在当前目标、参数、上下文、环境状态和委托链下，这一次调用到底应不应该发生”。

例如，同一个：

vehicle.unlock_door

在下面几种场景中，安全结论完全不同：

车辆静止、车主本人、手机在附近；
车辆高速行驶；
请求来自远程 Sub-agent；
Agent 的当前任务只是查询车辆状态；
Tool 参数突然从“读取”切换为“执行”；
前一个 Tool Result 来自一个刚刚被发现存在风险的 MCP Server。

Agent 的实际风险是动态的。

因此，真正的 Runtime Decision 至少需要同时考虑：

Identity × Capability × Parameter × Context × State × Delegation × Irreversibility

这也是 Agent Runtime Security 与传统 IAM 的关键区别。

IAM 管“谁能访问什么”；运行时 Harness 还需要判断“为什么现在要做、以什么参数做、当前状态是否允许做”。

六、Agent Supply Chain Security 正在形成怎样的技术闭环？

一套完整的 Agent 供应链安全体系，不应该只在下载或安装时扫描一次。

更合理的闭环是：

可以把它概括成九个动作：

Discover → Identify → Vet → Understand → Admit → Observe → Detect Drift → Revoke → Learn

这也是 Agent Supply Chain Security 和 Agent Runtime Security 必须结合的原因：

供应链安全提供 Trust；
Runtime Harness 执行 Policy；
Runtime Monitor 提供 Evidence；
Threat Intelligence 持续更新 Reputation。

只做其中任何一个点，都很难形成真正闭环。

七、AIR 为什么值得关注：一个“品类形成”信号

AIR Security 并不是全球唯一在做 Agent Security 的公司。

目前 Palo Alto Networks、Cisco、Snyk、Checkmarx、Cloudflare、Microsoft、AWS，以及 Runlayer、Noma、Zenity、Operant AI 等公司，都已经从 MCP Security、AI-BOM、Agent Identity、Agent Gateway、Runtime Protection 等不同方向进入这一问题域。

但 AIR 值得特别关注的地方，是它把一个过去分散的问题直接定义成了产品对象：

企业里的 Agent 正在不断安装和连接第三方能力，因此这些能力本身需要持续的供应链审核。

据 TechCrunch 2026 年 9 月 1 日报道，AIR 已获得两轮合计 5000 万美元种子融资，首轮由 Sequoia 领投，第二轮由 Greenoaks 领投。其公开产品重点包括 Agent Discovery、Skills / Plugins / MCP / Add-ons 持续审核、阻断不可信组件和经过审核的 Marketplace。

这并不能证明“Agent Supply Chain Security 已经是一个成熟、独立的企业预算品类”。

但它至少说明：

Agent Add-on Vetting 已经从安全研究议题，开始进入独立产品和资本市场验证阶段。

参考：

AIR: https://www.air.security/
TechCrunch: https://techcrunch.com/2026/09/01/air-raises-50m-to-help-companies-vet-the-skills-and-add-ons-ai-agents-use/

八、从企业 Agent 到汽车和机器人：为什么风险会进一步升级？

为什么汽车和机器人中的 Agent Supply Chain Security 更重要？

汽车和机器人中的 Agent Supply Chain Security 与普通企业 Agent 最大的区别，是供应链组件最终可能产生物理副作用。

企业 Agent 的高风险动作通常是：

删除数据；
发送邮件；
修改云资源；
发起支付；
操作企业系统。

车辆和机器人则可能进一步走向：

车辆解锁；
诊断服务调用；
ECU 写入或 Routine Control；
车身能力调用；
ROS2 Service / Action 调用；
机器人运动控制；
机械臂执行；
其他 Cyber-Physical Action。

因此，在汽车和机器人中，信任链会变成：

Agent → Skill → MCP / Tool → Vehicle / Robot Service → ECU / Controller → Physical Action

这条链路的安全要求明显高于普通办公 Agent。

企业 Agent 与汽车/机器人 Agent 的风险升级路径如下：

不能只做“企业 MCP Gateway 的汽车版”

对于汽车和机器人，至少还需要考虑六个现实约束：

1. 实时性

关键动作不能依赖不可预测的云端安全串行调用。高风险能力需要端侧、本地、确定性的最小安全裁决。

2. 离线

车辆和机器人都可能断网。关键策略、撤销列表和 Capability Policy 需要支持本地缓存和可信降级。

3. OTA

Skill、Tool Definition、Agent Runtime、Policy 都可能随 OTA 发生变化，因此 Agent 供应链安全还需要进入发布、灰度和回滚体系。

4. 功能安全边界

Agent 安全不能代替功能安全机制。它应该限制 AI 能力如何进入 Vehicle / Robot Service，而不是取代底层 Safety Mechanism。

5. 领域能力语义

send_email 和 vehicle.body.unlock 并不是同一类风险。

汽车需要理解 Vehicle SOA、UDS / DoIP、ECU Domain；机器人需要理解 ROS2 Topic / Service / Action 与物理执行对象。

6. 不可逆动作

读取车辆状态与执行控制，不能只被视为同一个 Tool 的不同参数。

Physical Side Effect 和 Irreversibility 应该成为 Agent Capability Risk 的一部分。

九、木卫四的判断：AI 安全正在从“内容安全”进入“能力安全”

过去两年，AI 安全讨论主要集中在：

Prompt Injection；
Jailbreak；
Sensitive Data；
Hallucination；
Output Safety。

这些问题依然重要。

但随着 Agent 获得 Tool、Skill、MCP 和 Sub-agent，安全边界正在继续向外扩展：

从“模型生成了什么”，进入“Agent 被允许获得什么能力，以及这些能力最终产生了什么动作”。

木卫四认为，下一阶段的 Agent Security 至少需要形成四个互相连接的控制面：

1. Context / Privacy Security

判断 Agent 看到了什么数据，哪些 Context 可以进入模型和 Memory。

2. Supply Chain Trust

判断 Skill、MCP、Tool、Sub-agent、Publisher、Version 和 Dependency 是否可信。

3. Runtime Harness

在真实动作发生之前，根据 Identity、Capability、Parameter 和 State 做准入和裁决。

4. Runtime Monitor

持续记录 Agent → Context → Plan → Tool → Result → Real-world State 的完整轨迹，识别 Goal Drift、Plan Deviation、Tool Sequence 异常和组件行为漂移。

对普通企业 Agent，这套体系保护的是数字业务。

对智能汽车和机器人，它最终保护的是：

AI 获得真实世界行动权之后，行动权本身仍然处于可验证、可约束和可撤销的安全边界内。

木卫四提出的四个控制面关系如下：

十、企业现在可以先做什么？

Agent Supply Chain Security 仍处于早期阶段，企业并不需要一开始就建设一个庞大的新平台。

更实际的第一步是建立基本可见性和可信基线：

盘点 Agent 外部能力
识别实际在用的 Skills、MCP Servers、Tools、Connectors 和 Sub-agents。
绑定 Publisher、Version 和来源
不允许“名称一样就是同一个组件”，需要建立明确来源和版本关系。
建立 Capability Inventory
不只记录组件名称，还要记录它能读什么、写什么、删除什么、控制什么。
对高风险组件做持续审核
新版本、新 Tool Description、新权限、新 Endpoint 都应该重新评估。
把高风险动作放到 Runtime Gate
不让 Agent 因为“安装时审核通过”就永久拥有无条件执行权。
保留撤销与隔离能力
当威胁情报、行为漂移或版本风险出现时，能够快速 Block、Quarantine、Rollback。

企业越早建立这些基础数据，未来越容易从“管理 MCP”升级为真正的 Agent Trust Architecture。

核心数据与事实

事实	公开信息
AIR Security 走出隐身模式	2026-09-01
AIR 已披露融资	两轮种子融资合计 5000 万美元，TechCrunch 报道
MCP Registry	已进入 Preview，提供公共 MCP Server 元数据、命名空间和版本机制
Agent Skills	已形成开放规范，Skill 可以包含说明、脚本、参考资料和资产
A2A	2026-08 加入 Agentic AI Foundation
Postmark MCP	已出现真实恶意 npm 包案例，并获 Postmark 官方确认
Tool Poisoning	已被 Invariant Labs、OWASP 及多项学术研究公开验证
大型安全厂商	Cisco、Palo Alto Networks、Snyk、Checkmarx 等均已增加 Agent / MCP / AI Supply Chain 相关能力

注：Agent Supply Chain Security 目前已经形成明确技术问题域，但企业市场的独立预算品类仍在形成过程中。将其描述为“成熟赛道”仍然过早。

FAQ

Agent Supply Chain Security 和 MCP Security 是一回事吗？

不是。MCP Security 是 Agent Supply Chain Security 的重要子集。 Agent 的外部能力还可能来自 Skills、Plugins、Connectors、Sub-agents、A2A Agent、外部 Context 等。真正需要保护的是完整 Agent Capability Supply Chain，而不是某一种协议。

Agent Skill 为什么属于软件供应链？

因为现代 Agent Skill 不一定只是提示词。它可以包含脚本、资源文件、外部依赖、工具调用和执行说明，并且会改变 Agent 可以完成的任务范围。因此它同时具有软件组件和能力扩展组件的属性。

有了 SBOM 和 SCA 以后，还需要 Agent Supply Chain Security 吗？

需要。SBOM 和 SCA 主要识别代码组件、依赖和已知漏洞，但无法完整表达 Tool Description、语义权限、Context Provenance、动态委托和行为漂移。Agent 供应链需要继承传统软件供应链能力，再增加语义与运行时控制。

为什么代码签名也不够？

签名可以证明“这个版本确实由某个 Publisher 发布、内容没有被中途篡改”，但无法证明 Publisher 本身可信，也无法证明合法发布的新版本没有扩大权限、增加恶意语义或改变后端行为。

Tool ACL 为什么不够？

ACL 主要表达静态权限，而 Agent 的安全决策依赖当前目标、参数、Context、环境状态、前序行为和 Sub-agent 委托关系。高风险 Agent 需要 Runtime Policy，而不仅是静态 Allow/Deny。

Runtime Monitor 在供应链安全里有什么作用？

运行时监控可以验证“审核通过的组件在真实环境里是否仍按预期行为”。如果 Tool Definition、Endpoint、调用序列或实际副作用发生变化，Monitor 可以把新的证据反馈给 Trust / Policy 系统，触发降权、隔离或撤销。

汽车和机器人为什么需要更严格的 Agent Supply Chain Security？

因为它们的 Tool 和 Capability 最终可能连接车辆控制、诊断、机器人运动或其他物理执行接口。供应链风险不再只影响数据和账号，还可能形成现实世界副作用。

十条可独立引用的结论

Agent 软件供应链安全保护的不是某一种协议，而是 Agent 从第三方能力到真实动作的完整信任链。
MCP Registry 可以提高身份和版本可验证性，但 Registry 本身不能证明 Tool 的语义、权限和运行时行为持续可信。
Agent Tool 的特殊之处在于，它既可能执行代码，也可能通过描述、上下文和返回内容直接影响模型决策。
Postmark MCP 等案例说明，传统恶意包、品牌冒充和 Rug Pull 已经开始迁移到 Agent 工具生态。
Tool Poisoning 表明，没有 CVE 并不等于 Agent Tool 安全，语义内容本身也可能成为攻击载体。
传统 SBOM 需要继续使用，但 Agent 时代还需要进一步建立 Add-on BOM 和 Capability BOM。
Tool ACL 只能表达静态访问权，Agent Runtime Security 还需要判断当前目标、参数、状态和委托关系下这一次动作是否合理。
Agent Supply Chain Security 的完整闭环应该包含发现、审核、准入、运行时持续验证和撤销，而不是安装时扫描一次。
汽车和机器人中的 Agent 安全更复杂，因为 Agent Capability 最终可能连接真实物理动作。
AI 安全正在从“模型内容安全”继续进入“Agent 能力安全”和“行动权安全”。

总结

AIR 的 5000 万美元融资不是 Agent Supply Chain Security 成立的唯一证据，但它是一个值得关注的时间节点。

更重要的变化来自整个生态：

MCP 正在形成 Registry，Agent Skills 正在标准化，A2A 正在连接更多 Agent，云平台正在建设 Agent Registry、MCP Gateway 和 Agent Identity，安全厂商开始加入 AI-BOM、MCP Vetting、Agent Runtime Protection。

与此同时，Postmark MCP、Tool Poisoning、多 Tool 组合攻击已经证明：Agent 的第三方能力并不是普通“插件”。

它们正在成为 Agent 的新软件供应链。

对于智能汽车和机器人，这个问题还会更进一步——当 Agent 最终可以调用 Vehicle Service、诊断能力、ROS2 Service 或其他物理执行接口时，安全系统需要保护的不只是模型，而是整个：

Agent → Capability → Action

链路。

这可能是 AI Security 下一阶段最重要的变化之一：

模型可以拥有越来越强的推理能力，但真实世界的行动权必须始终被更严格地管理。

主要公开参考资料

AIR 与市场信号

AIR Security: https://www.air.security/
AIR Out of Stealth: https://www.air.security/blog-posts/out-of-stealth
TechCrunch, 2026-09-01: https://techcrunch.com/2026/09/01/air-raises-50m-to-help-companies-vet-the-skills-and-add-ons-ai-agents-use/

MCP、Agent Skills 与 A2A

MCP Registry: https://modelcontextprotocol.io/registry/about
MCP Registry Authentication: https://modelcontextprotocol.io/registry/authentication
MCP Registry Versioning: https://modelcontextprotocol.io/registry/versioning
Agent Skills Specification: https://agentskills.io/specification
Agent Skills GitHub: https://github.com/agentskills/agentskills
A2A Specification: https://a2a-protocol.org/v0.2.6/specification/
A2A / Agentic AI Foundation: https://a2a-protocol.org/latest/blog/2026/08/27/a-new-chapter-for-a2a-joining-the-agentic-ai-foundation/

攻击案例与安全研究

Koi Security / Postmark MCP: https://www.koi.ai/blog/postmark-mcp-npm-malicious-backdoor-email-theft
Postmark 官方说明: https://postmarkapp.com/blog/information-regarding-malicious-postmark-mcp-package
Invariant Labs / Tool Poisoning: https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
OWASP MCP Tool Poisoning: https://owasp.org/www-community/attacks/MCP_Tool_Poisoning
MCPTox: https://ojs.aaai.org/index.php/AAAI/article/view/40895
ShareLock: https://arxiv.org/abs/2606.27027

平台与安全产品

Cisco AI Defense: https://blogs.cisco.com/ai/securing-agents-ai-supply-chain-with-cisco-ai-defense
Palo Alto Networks Agent Security: https://www.paloaltonetworks.com/prisma/agent-security
Snyk + Invariant Labs: https://labs.snyk.io/resources/snyk-labs-invariant-labs/
Cloudflare MCP Governance: https://developers.cloudflare.com/agents/model-context-protocol/protocol/governance/
Microsoft Agent Registry: https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-registry
AWS Bedrock AgentCore Gateway: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using.html
Alibaba Cloud AI Registry: https://www.alibabacloud.com/help/en/mse/user-guide/what-is-the-ai-registry-ai-governance-center-2
Tencent Cloud AI Agent 安全网关: https://cloud.tencent.com/document/product/1627/78612

关于木卫四科技（Callisto）

木卫四科技长期聚焦智能汽车与智能设备网络安全。面向 AI Agent 进入座舱、维修、诊断、机器人等真实业务场景后出现的新安全边界，木卫四持续研究 Context / Privacy、Agent Runtime Harness、Runtime Monitor、Threat Intelligence 以及 Cyber-Physical AI Security 等技术方向，探索让 AI 在获得更强能力的同时，保持行动权可验证、可约束、可审计。