Assaf Rappaport正向一类新操作者开放Wiz的云安全图谱：人工智能智能体。2026年7月，Wiz正式开放其模型上下文协议服务器，使兼容的助手和定制智能体能够查询安全上下文。公司还将AI安全平台扩展至基础设施、数据、访问、模型、智能体和应用。
其吸引力显而易见。安全团队面对的警报、资产和软件变更数量，已超出人力逐一检查的能力。接入Wiz的智能体可以回答哪些暴露于互联网的工作负载含有敏感数据，识别其负责人，并起草修复方案。它还可以把相关背景信息带入工程师已经使用的工具。
掌握情境后可以迅速采取行动。智能体可能更改云策略、隔离工作负载、轮换凭证或发起代码修复。拉帕波特必须确保，这种速度不会把尚不确定的安全发现变成生产环境故障。这个平台的价值既取决于模型的智能水平，也同样取决于权限、证据和操作的可逆性。
关系图谱是一项战略资产
Wiz围绕云资源、身份、漏洞、数据和网络暴露之间的关系构建平台。单独一个漏洞的优先级可能很低；但如果同一漏洞出现在可从外部访问且能接触敏感信息的系统上，就可能需要紧急处理。这种关系图谱帮助团队聚焦于那些会形成真实攻击路径的风险组合。
智能体恰恰需要这类情境信息。通用模型可以解释漏洞，却不了解一家公司的架构、权责归属和控制措施。通过受治理的接口，模型可以获取最新事实，并依据客户的实际环境提出建议。
图谱还可以连接技术语言与商业语言。高管可能会问哪些关键服务面临风险，工程师则需要了解具体资源和策略。只要底层关系准确且权限得到执行，智能体就能在这两个层面之间转换。
拉帕波特应避免把该图谱变成不受限制的数据池。每次查询都应符合调用者的角色和目的。开发人员可以查看其负责服务中的风险；中央安全团队则可拥有更广泛的可见范围。敏感发现若暴露给错误的智能体，本身也可能成为攻击情报。
MCP扩大了攻击面
模型上下文协议对模型与工具之间的连接进行标准化。这可以简化集成，但也形成了指令、数据和操作流转的通道。嵌入工单或代码库的恶意指令可能试图诱导智能体泄露调查结果或调用不当工具。
Wiz应当假定模型可能遭到操纵。MCP服务器需要强身份认证、限定范围的令牌、速率限制和明确的工具定义。读取权限应与写入权限分开。客户应能按项目、云账户、数据类别和时间限制查询。
审计日志必须记录用户、智能体、模型、指令上下文、检索数据与拟议行动。日志应具备防篡改能力，并可供客户监控系统使用。缺少这条链路，机构既无法调查智能体为何得出某项结论，也无法证明合规。
版本管理同样重要。安全数据持续变化，模型也会随时间演变。一项决策应记录当时采用的图谱状态和政策。否则，日后重放同一请求可能得到不同答案，却没有任何解释。
阅读、推荐和采取行动属于不同的风险等级
Wiz可以分阶段构建自动化。只读智能体可以检索发现并归纳风险；建议型智能体可以在证据支持下提出修复方案；行动型智能体则可以调用云端或开发工具。每一阶段都需要更严格的控制。
许多机构应从前两项着手。充分准备的建议可以为工程师节省大量时间，同时不允许智能体改动生产环境。当变更影响关键服务时，审批可以同时要求资源负责人和安全团队参与。
低风险操作最终或可自动运行。创建工单、要求指定负责人或添加经测试的标签都较容易撤销。禁用访问权限、删除资源及更改网络策略则需要更严格的限制。Wiz应提供默认风险分类，同时允许客户自行调整。
可逆性需要设计，而不是假设。在更改之前，代理可以捕获当前状态、测试依赖关系并生成回滚。如果环境与计划不同，则应停止。行动后检查应确认风险已降低且不会中断服务。
自动化质量需要可量化的证据
智能体演示往往展示一条成功路径，企业买家则需要了解失败率。Wiz应衡量错误确定优先级、上下文不完整、不安全提议、审批否决和回滚频率。结果应按云平台、工作负载和操作类型细分。
与人类进行比较有用，但还不够。智能体可能处理更多发现，同时产生日后才会显现的细微错误。评估应涵盖红队场景、归属权模糊、数据过时和政策冲突。外部研究人员可以协助测试指令注入或权限过度是否会绕过控制措施。
客户需要在启用操作前，拥有自行开展评估的工具。模拟模式可以展示智能体在过往事件中原本会作出哪些改动。政策可要求在提高自主程度前，先达到一定数量的成功受监督运行。
拉帕波特应将安全措施纳入商业产品本身，而不是作为可选的服务项目。规模较小的组织评估智能体的能力可能最为有限，自动化的冲动却最为强烈。安全的默认设置能够保护这些组织，并降低系统性风险。
谷歌的所有权同时增强了能力，也加大了审视压力
Wiz于2026年3月完成并入Google Cloud，同时保留其品牌和多云承诺。借助谷歌的模型、威胁情报和基础设施，公司可以加快智能体开发。谷歌的分销能力则能将这些工具带给更多企业。
这层关系也引发了有关中立性的问题。Wiz智能体必须以审视Google Cloud时同样的清晰标准，识别AWS和Azure中的风险。它们还应支持多家供应商的模型和开发者工具。客户需要确信，安全上下文不会被用来偏袒谷歌产品。
数据边界至关重要。Wiz的调查结果包含敏感的架构信息。未经明确许可，谷歌不应使用客户安全数据训练无关模型或为竞争性销售提供参考。合同、技术控制和可审计性都必须为这一承诺提供保障。
拉帕波特的职责，是在利用母公司资源的同时维护这家安全公司的公信力。智能体平台提供了一项现实检验。多云客户将判断其集成、发布时间及建议是否继续保持平衡。
安全团队需要新的运营模式
智能体带来的不只是生产率提升，还会改变工作的执行者与责任承担者。安全分析师或许会减少收集数据的时间，把更多精力用于制定政策、评估例外情况和调查复杂攻击。工程师则会在开发流程更早阶段获得建议。
机构应明确智能体权限与评估工作的责任人。仅由安全工具管理员决定智能体可以在生产环境中更改什么，远远不够。应用、云服务、法务和风险管理负责人需要建立共同治理流程。Wiz可以提供模板，但最终责任仍由客户承担。
培训应包括如何质疑智能体。用户需要审查证据、识别不确定性并报告有害行为。措辞流畅自然的回答可能显得比实际更可靠。界面应呈现置信程度和缺失数据，而非将其隐藏。
自动化也可能改变人员配置的经济账。在智能体尚不能可靠应对事故和架构变化之前，企业不应基于预期效率缩减团队。当模型遇到陌生情况时，人类专业能力仍是后备保障。
采购与责任归属不能继续含糊不清
购买智能体能力的企业会追问：自动修复造成损失时，责任由谁承担。Wiz可以提供工具和默认设置，但合同应明确客户、模型提供商、云平台与Wiz之间的责任边界。宽泛的免责声明会削弱实现自主运行所需的信心。
保险和审计团队会要求提供控制措施的证据。可导出的审批日志、评估结果和变更记录可支持此类审查。服务水平应涵盖上下文的可用性和政策执行，而非保证模型的每次判断都正确。
采购流程还应区分预览功能和可投入生产的操作。标记为实验性的功能不应通过一般性平台审批获得特权访问权限。管理员需要一份智能体工具目录，列明其风险等级和责任人。
拉帕波特可以通过提供标准化文档、适用于不同地区的数据条款和部署方案，降低治理难度。减轻这类管理负担本身就是产品价值的一部分。如此一来，安全团队便可采用实用的自动化工具，而无须为每次系统接入临时设计一套法律与管控框架。
胜出的控制层将逐步赢得授权
Wiz的安全图谱为拉帕波特提供了一个机会，使其成为企业安全智能体的上下文层。这一地位可能比任何单一模型更持久，因为它依赖实时的客户关系、政策和资产。但如果工作流难以导出，也可能造成深度依赖。
公司应保留接口文档，并允许客户提取日志、政策和调查结果。开放性有助于建立信任，也使企业能够组合专业化智能体。通过无法访问的上下文实现锁定，将招致抵制和监管关注。
Assaf Rappaport可以推动安全工作从告警管理转向受监督的行动。路径应当循序渐进：答案有据可查、建议可以解释、工具权限受到限制、执行可以撤销。如果Wiz能证明自动化可以降低风险，同时不会制造新的高权限故障点，其图谱可能成为关键的智能体基础设施。如果它推进自主化的速度超过治理能力，这个旨在保护云端的系统可能反而成为云端最强大的风险之一。
