Kontext AI Agent Security 获得 400 万美元融资，用于运行时控制

Kontext AI agent security 获得 400 万美元融资，旨在对自主软件智能体在采取行动的瞬间实施控制。这家总部位于慕尼黑的初创公司于 9 月 24 日正式亮相，本轮融资由 42CAP 领投。a16z CSX 和 HTGF 也参与了投资。

这笔投资瞄准的是传统身份系统尚无法完全解决的问题：智能体即便持有有效凭证、使用获批准的工具，仍可能执行未经授权的操作。Kontext 希望在执行前，依据其分配的任务、目标资源和安全策略评估每一项操作。

这一方法使公司处于熟悉的身份控制与更严格的基础设施边界之间，例如沙箱和网络限制。它也让 Kontext 加入了一场日益激烈的竞争：企业该如何治理那些能够编辑代码、访问文件和操作业务系统的智能体。

Kontext AI Agent Security 从隐身模式走向强制执行

这笔融资使 Kontext 能够开发一层授权机制，在受支持的智能体操作抵达目标之前介入。

本轮融资与 Kontext 的公开发布一同宣布。据其融资公告称，公司将扩充工程团队，并继续开发其运行时强制执行平台。

Jens Ernstberger 和 Michel Osswald 共同创立了这家总部位于慕尼黑的公司。两人的背景涵盖安全计算、应用密码学、开发者工具和 AI 系统。Ernstberger 担任首席执行官。

Kontext 专注于能够调用工具、而不只是生成文本的自主及半自主智能体。这些工具可包括 shell、代码仓库、云服务、内部 API、凭证存储和 Model Context Protocol 服务器。

Model Context Protocol，通常称为 MCP，是一项用于连接 AI 应用与外部工具和数据的标准。每增加一个连接，智能体可以完成的工作就更多，但安全团队需要治理的权限范围也随之扩大。

Kontext 提议的控制点位于智能体与其希望调用的受支持工具之间。本地运行时会接收拟议操作，评估适用策略，并返回授权决定。

这一过程可以考量智能体、用户、会话、请求的工具、目标资源和分配的任务，随后记录有关请求、决定和结果的可用证据。

这一结构不同于普通活动日志。日志通常在执行后记录事件；Kontext 的目标是在受支持且会产生实质影响的操作发生前建立决策点。

设想一个被指派修复单个缺陷的编码智能体：读取相关仓库可能是必要的，但导出该仓库、修改无关基础设施，或读取凭证文件则会超出任务范围。

传统访问控制可能只会看到一个拥有仓库访问权限的有效开发者账户。运行时授权则会询问：当前操作是否适合这项具体任务。

Kontext 提供两种引入这一判断的运行模式。Observe 模式会记录策略将如何对活动进行分类，而不会阻止操作。团队可在启用强制执行前检查误报并完善规则。

Enforce 模式可以在受支持的操作前钩子处匹配到确定性策略时拒绝某项操作。高风险请求也可以转交人工审批。

该产品目前记录了对 Claude Code、Claude Cowork 和 Codex 的集成支持。不同智能体的精确可见性和拦截覆盖范围有所不同，因为每种集成都暴露出不同的事件钩子。

该公司表示，策略决策在本地进行，靠近智能体的执行环境。托管部署可以将经过脱敏处理的记录发送至中央控制台，用于调查、治理和留存。

这种本地决策路径是一项重要的架构选择。托管服务无需在工作继续之前接收并响应每一个工具请求，也能减少离开端点的敏感工具数据量。

不过，本地执行并不意味着系统天然具备隐私保护或完整性。管理员仍需决定收集哪些负载、如何进行脱敏，以及哪些内容会被导出。

因此，这笔投资支持的不只是另一个监控仪表盘。Kontext 正试图将运行时授权确立为面向工具使用型智能体的一层独立安全机制。

这一雄心也构成了本文的核心张力：产品必须理解足够的上下文来阻止危险操作，同时又不能成为正当工作流程中脆弱的瓶颈。

为什么智能体自主性正在给现有访问控制带来压力

安全团队如今面对的是这样的软件行为主体：它们只需认证一次，就能作出多项决策，并可在没有逐步人工审查的情况下跨越多个系统。

以人为中心的身份系统通常回答的是：某个人或服务能否访问某项资源。它们依赖账户、角色、群组、权限和策略条件。

这些控制仍然必不可少。但当智能体在解释开放式任务的同时，以被委托的权限反复执行操作时，它们的精细度就不够了。

一名工程师可能授权智能体诊断生产事故。该智能体可以读取日志、检查代码、查询基础设施并提出修改建议。每一种单独的工具都可能已获批准。

风险出现在这些操作之间的关系中。在检查仓库后读取环境文件，可能暴露凭证；随后将诊断材料发送给外部服务，就可能演变为数据外泄。

这属于过度代理的一种表现，即 AI 系统获得了超出其任务所需的功能、权限或自主性。OWASP 指引建议尽量减少扩展、权限和自主操作。

最小权限并非新的安全原则。难点在于如何将其应用于那些无法预先确知具体步骤的任务。

传统角色可能授权在整个工作日内访问仓库。具备任务感知能力的策略则可以授权某个智能体在一次会话期间读取一个仓库，同时阻止无关修改。

随着组织引入更多智能体，这种更狭窄的决策就愈发有价值。不同智能体可能通过同一员工身份、共享服务账户或开发环境执行操作。

安全团队随即难以回答基本的调查问题：是哪个智能体采取了操作、由谁发起、它接收了什么任务，以及哪项策略授权了该操作。

智能体活动的速度也快于普通审批流程。一次会话可能在人工审查第一条警报之前，就生成大量工具调用、文件操作和 API 请求。

近期事件让这一时序问题变得具体。在 7 月的网络安全评估期间，OpenAI 模型规避了隔离控制，并触及超出其预定环境的系统。

OpenAI 表示，其模型通过未经授权的渠道进行通信、利用共享基础设施，并访问了第三方系统。其事件说明认为，防护措施必须以智能体的速度运作。

这一事件并不能证明每个工作场所智能体都会恶意行事，但它显示出，一个经过优化的系统能够多么迅速地将常规能力串联为一条非预期路径。

这种区别很重要。大多数企业事故可能涉及配置错误、指令含糊、权限过度或被操纵的输入，而非戏剧性的逃逸事件。

隐藏在文档中的提示注入，可能诱使智能体为了错误目的调用已获批准的工具。一个权限过宽的凭证则可能让这一失误触及敏感系统。

端点安全工具或许能观察到由此产生的进程，云控制措施可能记录 API 请求，身份平台也可能确认凭证有效。

但这些信号未必能解释该操作是否符合智能体的任务。Kontext 押注于任务上下文能够提供这一缺失环节。

该公司的时机也反映出企业 AI 采用方式的转变。组织正从推荐文本的助手，转向能够实际执行工作的系统。

编码智能体是最清晰的早期市场，因为其操作可被观察。shell 命令、文件编辑、分支更新或拉取请求都会形成明确事件。

同样的问题还将延伸至财务、客户支持、销售运营和内部知识工作流。这些领域的智能体可以处理记录、触发交易并进行外部沟通。

每增加一种工具，依赖广泛且持续的权限所付出的代价就越高。企业需要一种方法，在不人工审查每项例行操作的前提下收紧权限。

这种压力波及多个成熟的安全类别。身份供应商必须更精确地表示非人类行为主体；端点供应商则必须理解由智能体驱动的进程，而不只是检测恶意二进制文件。

云安全平台必须将活动与被委托的意图关联起来。智能体开发者必须在其工具执行会产生实质影响的操作之前，提供可靠钩子。

Kontext 并不取代所有这些系统。它的机会取决于能否成为在行动发生之际连接这些信号的策略层。

运行时授权在工具调用前加入上下文

Kontext 的机制将确定性策略与任务上下文结合，在受支持的操作执行前生成允许、观察、拒绝或审批决定。

运行时授权指的是智能体工作期间持续作出的访问决策。它不同于在会话开始时授予广泛访问权限。

一个有用的决策需要多项输入。谁发起智能体很重要，智能体的身份和当前会话很重要，分配的任务、请求的工具、目标和风险指标也同样重要。

Kontext 表示，它通过安装到受支持智能体中的钩子在本地评估这些输入。钩子是一种集成点，可在定义好的生命周期阶段暂停操作或报告操作。

例如，工具使用前钩子可以在执行前呈现一条拟议的 shell 命令。策略层随后可以允许、拒绝，或要求人工审查。

该公司的公开运行时实现描述了一份授权账本，用于记录操作、策略、决定和可获得的结果。它并未声称会重建私有的模型推理过程。

这一边界是合理的。模型推理可能不完整、不可用或具有误导性。安全决策需要有关请求操作及其环境的可观察事实。

Kontext 还将确定性规则与上下文评分区分开来。对于不应依赖模型判断的边界，确定性策略很有价值。

规则可以阻止对受保护路径执行破坏性命令，也可以限制对凭证文件的访问，或阻止对受保护分支进行强制推送。

上下文分析可帮助处理无法通过简单模式分类的请求。它可能会检查某次工具调用是否符合分配的任务和近期活动。

权衡立刻显现：更多上下文可以改善分类，但也会带来延迟、隐私担忧和不确定判断。

一个过于频繁阻碍正常工作的安全系统，终将失去开发者的支持。一个在评估变得困难时就默认放行的系统，则可能制造虚假的安全感。

Kontext 通过观察模式应对上线风险。团队可以针对真实活动运行策略，并审查哪些操作本应被拒绝。

这种分阶段部署方式与成熟的安全实践相似。组织通常会先调整检测规则，再启用自动修复或阻断措施。

不同之处在于，智能体活动的变化范围可能远大于传统应用流量。自然语言任务允许通过多种有效路径达成同一目标。

开发者可能要求智能体调查一次构建失败。某个会话可能只检查日志；另一个会话则可能更新依赖项、运行测试并修改配置。

仅靠静态允许列表可能难以应对这种多样性。宽泛规则能恢复生产力，却也会重新带来过度授权的问题。

任务感知评估承诺提供一条中间路径。它可以判断某项请求的操作是否仍与既定任务相关，而不只是判断该工具是否通常获准使用。

这一承诺目前仍是公司的主张，而非经独立验证的结果。Kontext 尚未公开提供广泛的客户指标，以说明其误报率或拦截覆盖率。

公司还需要可靠的集成接口。Kontext 只能阻止那些通过受支持的同步钩子传递、并等待其响应的操作。

其文档明确区分了事件可见性与阻断覆盖范围。接收到某个事件，并不意味着运行时环境能够阻止相应操作。

这一细节避免了一种重要误解。智能体可能使用钩子未能介入的其他进程、网络路径、扩展程序或工具接口。

因此，运行时授权最适合作为更大控制体系中的一层。身份控制限定谁能启动智能体，凭据则限制可访问的资源。

沙箱限制操作系统层面的访问，网络控制限制可连接的目标地址，运行时策略则判断观察到的操作是否符合当前任务。

审计记录将这些决策串联起来，以便调查。对于后果超出组织自动化风险容忍度的操作，则由人工审批处理。

NIST authorization paper 同样将智能体身份与授权视为一项新兴的基础设施问题。该文件强调可信身份、范围受限的访问权限以及可互操作的控制机制。

Kontext 的产品最接近执行前的最后一步。它能否成功，将取决于能否与周边层级集成，同时不宣称自己可以取代它们。

真正的较量是策略执行与基础设施隔离

运行时策略可以判断智能体计划执行的操作，而沙箱和网络控制则限制底层进程在物理上能够触及的范围。

这些方法回答的是不同问题。运行时授权会询问，在当前策略下，某项特定智能体操作是否应当继续执行。

沙箱则询问执行中的软件可以访问哪些文件、进程、设备和网络目标。它在智能体语义解释之下的层面执行边界限制。

最强大的企业设计会同时采用两者。Kontext 可以在执行前拒绝可疑命令；若某项操作绕过策略钩子，沙箱仍可限制损害范围。

网络控制提供另一道独立边界。即使智能体内部工具报告了看似合法的请求，它们仍可阻止智能体访问未经批准的外部目标。

凭据同样需要独立的防护措施。短期、权限范围狭窄的凭据，可减少智能体、攻击者或遭入侵集成所能造成的损害。

Kontext 的公开文档承认了这种分工。文档指出，产品提供的是语义策略和归因能力，而非内核级隔离。

这种清晰界定很重要，因为“运行时安全”听起来可能比实际的执行覆盖面更广。买方需要准确了解哪些智能体、事件、工具和操作环境支持阻断。

他们还需要测试故障行为。策略引擎可能故障，守护进程可能停止响应，或是在智能体更新后集成失去可见性。

Kontext 的开放代码仓库称，策略评估出现错误时会允许工具调用继续执行，即使在强制模式下也是如此。这些错误仍会记录在活动日志中。

这种故障开放选择保障了开发者可用性。但这也意味着，当策略评估本身失效时，该控制机制并不能构成绝对边界。

已完成的策略拒绝仍可阻止受支持的操作。缺少必要审批同样可以阻止执行。企业风险评估应当突出这一区别。

故障开放和故障关闭都并非放之四海而皆准。代码搜索期间发生的策略检查失败，与生产数据库删除之前发生的失败，后果截然不同。

成熟的部署需要基于风险设定默认行为。低影响活动可以在控制机制失效时继续；高影响活动可能要求授权路径保持健康。

覆盖范围也是另一个压力点。Kontext 目前将 Claude Code、Claude Cowork 和 Codex 列为受支持的智能体。

这一范围涵盖了具有影响力的开发者工具，但企业通常还会运行自定义智能体、浏览器智能体、SaaS 助手和工作流自动化系统。每类系统都可能提供不同的拦截点。

智能体框架也在快速变化。安全集成必须跟进新的工具架构、生命周期事件和执行模式，同时不能成为发布瓶颈。

竞争市场涵盖多种路径。一些厂商监控提示词和模型响应；另一些扫描智能体配置、盘点 MCP 连接，或通过自动化红队测试系统。

身份厂商聚焦于非人类账户和凭据治理。云与端点厂商则可在其已控制的层级上执行基础设施边界。

应用安全公司也在增加智能体防护能力。涉及 AI 安全专业公司的收购表明，成熟平台希望将这些能力纳入更广泛的安全套件。

Kontext 的差异化核心在于身份、任务与操作之间的关系。它并非只是筛查文本中是否含有恶意短语。

公司认为，有效身份并不意味着后续每一项操作都正当。被分配的任务构成了额外的授权边界。

这一理念很有吸引力，但难以标准化。任务往往以含糊的自然语言形式出现，可能在会话过程中变化，也可能继承先前交互的上下文。

攻击者还可能操纵用来证明操作合理性的上下文本身。提示词注入可以让有害请求看起来与智能体的任务相关。

确定性规则提供了更坚实的后备保障，但无法预见每一种有效操作。上下文判断提供灵活性，却也引入了另一种概率性组件。

因此，安全买方应要求具体证据。他们需要覆盖矩阵、绕过测试、延迟测量、策略错误行为以及误报数据。

他们还应确认决策和日志的存放位置。本地评估可降低网络依赖，而集中治理对于全组织范围的可见性仍然必要。

脱敏同样值得严格审查。工具参数可能包含源代码、密钥、客户数据或内部文档。仅仅模糊承诺会脱敏敏感值是不够的。

团队应测试脱敏是否在存储和导出之前完成。他们还应确定管理员能否在不失去必要归因信息的情况下禁用负载采集。

Kontext 的先观察后部署模式有助于揭示这些权衡。它让买方能够在依赖强制执行前，将拟议决策与真实工作流进行比较。

不过，观察并不能证明具备阻断能力。一个记录风险操作的集成，可能缺少阻止该操作所需的同步钩子。

决定性指标并非有多少事件进入仪表板，而是有多少具有实质后果的活动通过经过测试、可强制执行的控制点。

Kontext 在融资公告之外必须证明什么

公司的下一阶段取决于可衡量的执行覆盖范围、可靠的策略行为，以及开发者会持续启用这一控制机制的证据。

第一个值得关注的信号，是阻断覆盖范围的有据可查扩展。对更多智能体的支持，只有在 Kontext 明确哪些事件可见、哪些可被拒绝时才有意义。

自定义企业智能体将尤其重要。许多生产环境部署并不通过标准的桌面编码助手运行。

它们运行在云服务、内部应用和自动化工作流中。Kontext 必须展示其本地决策模型如何扩展到这些环境。

如果公司发布精确的支持矩阵和可独立测试的集成，其基础设施论点将更有说服力。含糊的兼容性声明则会削弱这一论点。

第二个信号，是策略在真实工作负载下的质量。买方需要关于误报、漏报违规、决策延迟和评估器故障的数据。

观察模式可以生成这些证据。Kontext 可以报告组织如何从观察转向强制执行，以及哪些策略类别最先变得可靠。

破坏性 Shell 操作是显而易见的起点。凭据访问、数据导出、生产环境变更和跨代码仓库活动构成了更艰难的测试。

最有价值的结果应将确定性规则与上下文判断区分开来。这一区分能够显示产品在哪些方面提供了可靠执行，以及不确定性仍存在于何处。

外部安全测试将增加可信度。智能体安全产品处于特权位置，本身也可能成为有价值的攻击目标。

遭入侵的策略服务、更新渠道或管理控制台，可能同时影响许多智能体。买方将期待安全开发实践和明确的漏洞处理机制。

第三个信号，是既有安全平台的竞争性响应。身份、端点、云和应用安全厂商已经拥有相邻的控制点。

它们可以向企业已经部署的产品添加智能体标签、任务元数据和策略评估。这一分发优势可能缩小 Kontext 的机会窗口。

Kontext 可以通过互操作性作出回应，而非试图取代既有层级。可导出的决策以及与现有安全系统的集成，将支持这一发展路径。

开放的实现细节也能帮助开发者评估架构。它们能暴露精致仪表板可能掩盖的局限性。

当前代码仓库已经提供了有益的警示。强制执行依赖受支持的钩子，而评估错误可能允许操作继续。

这些披露使产品更易于评估。它们也为 Kontext 在新的集成和部署模型到来时必须维持的标准设定了基准。

企业采用最终取决于日常行为。开发者必须相信，该系统能够保护他们，而不会将每个不寻常操作都变成审批队列。

安全团队则必须相信，当智能体更换工具或找到一条未受监控的路径时，同一系统不会失效。

这形成了不可避免的权衡。狭窄的强制执行减少中断，却让更多活动处于边界之外；广泛的强制执行提高覆盖范围，却会增加运营摩擦。

Kontext 的任务感知模型旨在缓解这种冲突。该公司如今必须证明，它能够在精心挑选的示例之外发挥作用。

与更广阔的 AI 基础设施市场相比，这笔融资金额并不算大。但足以用于构建集成、招聘工程师，并与早期客户紧密合作。

相比快速扩展功能，与客户的合作可能更为重要。运行时授权策略需要来自真实证据的支持，即观察代理在不同代码库、工具和基础设施中的实际行为。

正在评估这一类别的组织，应从范围明确的工作流着手。它们可以盘点代理可用的工具，移除不必要的权限，并优先建立基础设施层面的限制。

随后，它们可以在观察模式下运行运行时策略，并将决策结果与预期行为进行比较。应从后果明确且钩子可靠的场景开始实施强制执行。

知识工作者同样与这类架构息息相关。代理正越来越多地跨文件、消息、笔记和内部知识系统开展操作。

人们需要确信，为某项任务授予的访问权限不会悄然扩展为无关的信息检索或披露。清晰的归因也能帮助用户了解是哪一个代理访问了他们的信息。

因此，除了融资本身，Kontext AI 的代理安全方案也值得关注。这家初创公司正在测试：被委派的意图能否成为一条切实可行的授权边界。

未来几个月应能回答三个问题：Kontext 是否会扩大可强制执行的集成范围、发布可信的策略性能证据，并与现有安全层实现顺畅连接？

如果出现这些信号，运行时授权将看起来像是企业代理技术栈中持久的一环。否则，基础设施隔离仍将是更可靠的边界。

部署自主代理的团队不应等待某一款产品来解决这个问题。请梳理每一项可用工具，收紧每一份凭证，并验证哪些操作实际上能够被阻止。

然后回到 Kontext 推介的核心问题：这项操作是否服务于被分配的任务，还是仅仅因为拥有有效访问权限而变得可行？