Mindgard 融资 3000 万美元，扩大 AI 安全测试业务

Mindgard 完成 3000 万美元 A 轮融资。随着企业将模型接入敏感数据和工具，这家 AI 安全初创公司获得了新的资金支持。这笔交易于 2026 年 8 月 14 日通过 Google News 报道曝光。它也让 Mindgard 的核心观点迎来明确检验：传统安全检查无法揭示在线 AI 应用中的所有漏洞。

据一份 A 轮融资报道，Album VC 领投本轮，Karma Ventures、.406 Ventures、Atlantic Bridge、IQ Capital 和 Lakestar 也参与了投资。Mindgard 此前曾于 2025 年 1 月宣布完成 800 万美元融资，由 .406 Ventures 领投。

新一轮融资到来之际，AI 安全厂商正围绕企业应将防线部署在何处展开竞争。一些产品监控提示词和模型回复；另一些则扫描模型、执行访问策略，或通过模拟攻击来测试完整应用。

Mindgard 希望让应用层安全测试成为这一技术栈的标准组成部分。它面临的挑战，是证明持续红队测试能够产出客户可复现、可排序并可修复的发现。

3000 万美元融资提高了 Mindgard 的赌注

Mindgard 已不再只是作为一个狭义的研究项目获得资金支持。投资者正将其视为企业安全平台来押注。

本轮融资之所以重要，是因为它提高了外界对公司的期待。一家规模较小的初创公司可以专注于技术验证、早期客户和单次安全评估；获得这一融资规模的公司，则还必须建立可复制的销售、集成、支持和可衡量的成果。

Mindgard 将其平台描述为一种发现 AI 系统、对其进行攻击测试、评估风险并在运行期间加以保护的方法。该公司关注模型、智能体和完整 AI 应用，而非只将底层模型视为唯一目标。

当 AI 系统能够检索企业文档、调用外部工具、修改记录或生成代码时，这一区别尤为关键。模型中的某个弱点，在受限演示环境中或许无害；但当应用能够访问机密信息或运营系统时，同一弱点就可能变得严重。

新投资者加入了多家早已了解该公司的机构。.406 Ventures、Atlantic Bridge、IQ Capital 和 Lakestar 也曾出现在 Mindgard 的 早期融资 中。它们再次投资表明持续看好，不过参与投资本身并不能独立验证产品成效。

公司尚未公开披露本轮融资的估值。现有公告也未说明营收、客户数量、合同增长情况，或持续运行测试的客户占比。

这些信息缺口限制了外界能够得出的结论。这笔融资确认了投资者对 Mindgard 战略的需求，但无法证明企业对该平台的采用范围，或其发现的问题有多频繁地最终得到修复。

Mindgard 早期的扩张计划强调美国市场，在波士顿设立领导团队，并持续在伦敦开展工程工作。最新融资令这一扩张承受更大压力。北美企业早已从大型平台厂商和专业 AI 安全公司采购安全产品。

因此，Mindgard 必须销售的不只是一个攻击库的访问权限。它需要证明，其测试能够融入开发流水线、安全运营和治理项目，同时不会以低优先级发现淹没团队。

最重要的事实不只是本轮融资的规模，更是随之而来的责任。Mindgard 现在拥有进军更大市场的充足支持，但如果客户难以将测试结果转化为更安全的系统，它也就更难找到借口。

为什么 Google News 此时聚焦 AI 安全融资

这笔融资出现在 Google News 上，是因为 AI 安全已经从研究议题转变为企业采购难题。

企业正将生成式 AI 部署到支持系统、文档搜索、软件开发、分析和内部自动化中。这些部署把概率型模型连接到传统安全团队原本就负责保护的系统。

概率型模型可能针对相似输入给出不同答案，也可能将不受信任的内容理解为指令。这些特性带来了无法直接映射到普通软件缺陷的失效模式。

提示词注入就是一个例子。攻击者将恶意指令嵌入 AI 应用处理的内容中，模型随后可能遵循这些指令，而不是开发者设定的规则。

越狱的目标则不同。它试图绕过模型的行为限制，生成提供商原本试图阻止的内容。这两类技术可能重叠，但带来的商业风险并不相同。

OWASP 维护的 LLM 风险清单还涵盖不安全的输出处理、过度代理权限、敏感信息泄露及其他应用层问题。这些类别超出了模型是否拒绝违规请求这一问题。

智能体系统让这种差异更加鲜明。普通聊天机器人只会生成回复；智能体则可以检索文件、使用凭证、执行代码、发送消息或修改业务记录。

这种能力会将误导性输出转化为潜在行动。被攻陷的智能体可能泄露数据、调用错误工具，或超出用户预期授权范围采取行动。

传统安全工具在这一环境中仍然重要。身份验证、访问控制、软件成分分析、端点保护、网络监控和安全开发实践，并不会因为应用包含 AI 而过时。

不过，这些控制措施并不总能解释模型在长对话中，或读取对抗性内容后会如何表现。安全团队需要在部署前后测试这种行为的方法。

这也解释了围绕 Mindgard 等公司的关注。该类别承诺将熟悉的应用安全工作与陌生的模型行为联系起来。

这一时机也反映出治理缺口。许多组织制定 AI 政策的速度，快于验证应用是否遵守该政策的能力。书面控制措施可能禁止访问敏感记录，但政策文本无法证明这种控制经得起攻击。

技术测试会将政策转化为可观察的主张。团队可以尝试提取数据、操纵工具选择、探查授权边界，并记录应用的响应。

Mindgard 押注于企业将这些演练视为持续性的安全工作。Google News 的曝光反映出日益增长的关注，但关注本身无法创造一个持久类别。买家仍需要证据证明，专用 AI 测试会改变其风险决策。

应用测试是 Mindgard 的核心押注

Mindgard 最具代表性的押注是，安全团队应攻击完整的 AI 应用，而不是评估孤立模型后就止步。

该公司将其方法称为面向 AI 的动态应用安全测试。动态测试检查运行中的应用，在这里，模型行为会与提示词、检索系统、API、工具、权限和防护措施相互作用。

Mindgard 表示，它可在这些层面自动化执行对抗测试。该平台会针对已部署的 AI 系统尝试提示词注入、越狱、数据提取、智能体操控及其他攻击技术。

这种方法遵循一项熟悉的安全原则：应用应在真实运行条件下接受评估，因为严重失效往往出现在组件交互之处。

一个模型在基准测试中可能表现安全，但周边应用可能暴露机密上下文。反过来，一个限制较少的模型，在无法访问私有数据或执行重大操作时，可能带来有限的商业风险。

Mindgard 曾表示，孤立的越狱结果往往缺乏排序所需的上下文。其 应用测试立场指出，团队应将一次成功攻击与真实系统、用户、资产和业务后果联系起来。

这一立场构成了 Mindgard 最强的差异化优势，也带来了运营负担。

测试完整应用需要上下文。测试人员必须了解有哪些用户、每位用户可访问什么、哪些操作重要，以及一次成功攻击意味着什么。

通用攻击提示词可以启动测试过程，但无法描述每个组织的威胁模型。医疗助手、编码智能体、金融工作流和面向公众的聊天机器人，需要不同的测试。

这使自动化成为必要条件，但并不充分。Mindgard 必须将可复用的攻击技术与客户特定配置结合起来。否则，该平台可能产出令人印象深刻的演示，却无法让安全团队将其转化为修复优先级。

可复现性带来了另一项挑战。当模型提供商更新服务、开发者调整提示词、检索内容变化或温度设置不同，AI 系统的行为也会改变。

一次测试成功的发现，可能在第二次测试时失败。这并不自动意味着原始结果毫无意义，但会使分诊更复杂。

安全团队需要足够证据来理解攻击路径，也需要日志、受影响组件、前置条件、影响范围和建议控制措施。

持续测试有助于观察变更过程中的行为；但如果每种变化都成为新的告警，持续扫描同样会产生噪声。

有用的衡量单位并非尝试了多少次攻击，而是团队能够复现并降低多少实质性弱点。

因此，Mindgard 的竞争不只在于攻击手法的成熟度，也在于工作流质量。一项技术上巧妙的漏洞利用，如果无法进入工单、开发和风险管理流程，其企业价值就很有限。

公司的平台战略表明，它理解这一要求。它主打集成和持续测试，而非将红队测试包装为偶尔开展的咨询服务。

A 轮融资让 Mindgard 有更多能力开发这些工作流，也让买家有理由要求证据，证明自动化在不降低发现质量的前提下，能够降低测试成本。

真正的竞争是测试与假定安全之间的较量

Mindgard 的主要对手并非某一家有名的初创公司，而是认为模型提供商防护措施和现有控制已经足够的假设。

企业应用从模型提供商、云环境、身份系统和开发框架中继承保护措施。每一层都能降低风险，但没有任何一层能够单独看清整个部署。

模型提供商可以测试基础模型，却无法知道客户检索系统中放入了哪些文档。它也无法完全预测开发者会添加哪些插件、工具或权限。

应用安全扫描器可以发现存在漏洞的依赖项和不安全的代码模式，却未必能检测到一段多轮对话如何说服智能体滥用合法工具。

治理平台可以记录政策、责任人和审批流程，却无法证明某个具体应用能够抵御真实可行的提示词注入攻击。

Mindgard 的核心主张是，对抗性测试能够提供缺失的证据。安全团队不应假设控制措施有效，而应测试攻击者是否能够突破这些措施。

这与既有的风险管理理念一致。美国国家标准与技术研究院发布的 AI risk framework 强调，应在 AI 系统的整个生命周期中衡量和管理风险。

测试只是这一过程的一部分。组织还需要治理、事件响应、访问管理、安全工程、监控以及明确的责任人。

这一更广泛的视角至关重要，因为任何红队测试平台都无法修复它发现的所有问题。某项发现可能需要收紧权限、调整系统提示词、加强输出验证、重新设计工具访问方式，或移除不安全的功能。

因此，核心竞争实际上在于验证与信任之间。企业应接受供应商和开发者提供的安全防护，还是应反复测试组装完成的系统？

对于高影响力应用，重复测试具有充分的合理性。系统变化过于频繁，单次评估很快就会失效。

模型版本持续演进。提示词不断变化。新工具陆续可用。员工添加新的数据源。攻击技术也在传播。

不过，持续测试需要边界。在生产应用中运行不受控制的攻击，可能影响成本、数据、用户或已连接的系统。

成熟的平台必须支持安全的测试环境、受控账户、限定权限和明确授权。它还必须区分模拟影响与会更改真实记录的操作。

这正是专业供应商能够创造价值的地方。对于缺乏专业 AI 红队能力的团队，它们可以将攻击方法、证据收集、报告和安全控制打包成产品。

这同样是大型安全供应商可以应对的领域。现有的应用安全和云安全平台已经拥有客户关系、遥测数据和工作流集成能力。

这些供应商可以增加模型发现、提示词监控、智能体测试或 AI 政策执行能力。如果能够收购专业公司或集成外部测试能力，它们无需重建每一项研究能力。

Mindgard 必须快速推进，以证明其方法值得成为一个独立的平台。公司的大学研究背景能够支撑其技术可信度。企业采用情况则将取决于这些研究成果能否转化为可靠的运营软件。

这轮融资未能证明什么

3,000 万美元融资验证了投资者兴趣，但并不能证明自动化 AI 红队测试能够持续降低企业风险。

融资公告自然会强调机会，但很少披露误报率、修复完成率、测试覆盖率、客户留存率或安全结果。

这些指标比生成攻击尝试的数量更重要。一个平台可以发起数千次探测，却仍可能错过通向敏感工具的那条攻击链。

它也可能识别出看似令人担忧的行为，却无法将其与实质性危害联系起来。基础模型生成不受欢迎的回答，与已认证的智能体泄露客户记录，是不同的问题。

第一个不确定性在于覆盖范围。任何有限的攻击库都无法代表所有提示词、模型、语言、应用架构或工具组合。

自动化系统可以改变攻击方式并搜索弱点，但它们仍受制于设计者设定的假设，以及客户提供的信息。

第二个不确定性在于评估。测试平台必须判断某个响应代表成功、失败还是模糊行为。

简单情况可以采用确定性检查。如果输出中出现了秘密字符串，结果就很明确。

其他情况则需要判断。某个响应可能部分遵从了有害指令、泄露了间接线索，或尝试了被其他控制措施阻止的未授权操作。

自动化评估器可以提供帮助，但基于模型的评判者本身也会带来不一致性。对于高影响力发现，人类审查仍然重要。

第三个不确定性在于修复。AI 漏洞并不总是存在单一补丁。

开发者可以过滤输入、限制工具、增加确认步骤、隔离数据、加强授权，或改变应用设计。每项控制措施都可能影响可用性和性能。

强大的测试平台应支持这一决策过程，而不只是重复攻击。它应展示攻击路径、触发条件、影响，以及拟议缓解措施的效果。

第四个不确定性在于市场结构。Mindgard 所处的市场中，专业厂商提供模型扫描、运行时监控、治理、护栏和红队测试等能力。

早期报道曾将 Noma、HiddenLayer 和 Protect AI 列为布局该市场部分领域的公司。随着大型安全平台扩展至 AI 领域，竞争格局仍在持续模糊。

当单一供应商能够结合发现、态势管理、监控和响应能力时，买家可能偏好整合型产品。专业厂商则可以通过提供更深入的测试，或支持大型平台忽视的模型和部署环境来取胜。

Mindgard 还发布漏洞研究，包括涉及 AI 编程工具和模型行为的发现。这类工作可以展示技术能力，但公开研究并不等同于产品在客户环境中的实际表现。

负责任披露带来了另一层复杂性。供应商、研究人员和客户可能会对严重程度、可复现性、受影响配置以及合理的修复时间表存在分歧。

读者应将个别披露视为特定条件下的证据，而非所有产品部署都不安全的证明。

因此，评估 Mindgard 的恰当标准是可衡量的客户影响。平台能否在攻击者之前发现重要弱点？团队能否复现这些发现？它们是否实施控制措施并验证这些措施确实有效？

这笔新融资让 Mindgard 有时间回答这些问题，但并不会代替公司给出答案。

Google News 标题之后值得关注的三个信号

下一阶段将由采用证据、产品集成和独立技术验证决定。

第一个信号是 Mindgard 是否披露可重复验证的企业成果。有价值的证据包括：已修复的重大问题占比、验证修复所需时间，以及运行定期测试的客户比例。

仅公布客户名称只能提供有限洞察。试点项目可以带来知名品牌标识，却无法证明持续使用。

长期结果会更具参考价值。如果客户在模型、提示词和工具发生变化后反复测试应用，Mindgard 的持续测试论点就会更有说服力。

如果大多数合作仍停留在一次性评估阶段，该平台可能更像自动化咨询服务。这依然可能具有价值，但支撑的业务范围会比持续安全基础设施更窄。

第二个信号是 Mindgard 与开发和安全运营的集成深度。值得关注其与持续集成流水线、模型注册表、云平台、工单系统和安全监控工具的连接。

集成深度会影响测试能否成为日常工作。对于每次发布都需要大量手动配置的安全产品，开发者不会持续使用。

安全团队也需要在现有工作流中获取结果。独立仪表板可以展示能力，但也可能变成无人负责的又一个待处理队列。

最强的实施方式应将某项发现关联到相关应用版本、责任人、受影响资产和修复工单。后续测试应验证修复是否真正改变了行为。

这条证据链对治理十分重要。它将有关负责任 AI 的抽象主张转化为经过测试的控制措施和有据可查的决策记录。

第三个信号是对 Mindgard 覆盖范围和准确性的独立验证。客户、安全研究人员、审计人员和对比评估可以检验该平台是否能发现有意义的弱点，同时不会产生难以处理的噪声。

MITRE ATLAS knowledge base 为防御者提供了描述针对 AI 赋能系统对抗性威胁的通用语言。映射到已获认可的技术可以帮助买家比较工具，尽管仅与框架对齐并不能证明有效性。

独立演练应包含真实的应用情境。仅测试孤立的聊天机器人，将无法验证 Mindgard 关于完整系统风险的核心主张。

买家也应审视失败案例。可信的评估会指出平台遗漏了什么、支持哪些环境，以及哪些环节仍需要人类专业能力。

这三个信号将决定融资公告代表的是品类领导地位，还是仅仅意味着竞争更激烈。采用证据将表明客户是否会回归。集成将表明产品是否融入日常工作。独立测试将表明其发现是否值得信任。

对于开发者和企业买家而言，实际的应对方式不是仅凭 Google News 标题购买产品。应先识别哪些 AI 应用能够访问敏感数据、工具或决策。

记录其责任人、模型、权限、检索来源和预期行为。需要保存这类工作可检索记录的团队，可以在知识库中整理技术证据。

随后测试影响最大的路径，并验证修复结果。Mindgard 的 A 轮融资使自动化应用测试更难被忽视。它的长期意义将取决于这种测试能否成为可靠证据，而非又一个安全承诺。