Curity 首席技术官 Jacob Ideskog – 专访系列

Jacob Ideskog 是一位身份专家，也是 Curity 的首席技术官。他的大部分时间都花在 API 和 Web 领域的安全解决方案上。他曾为大型企业部署以及小型初创公司设计和实施 OAuth 和 OpenID Connect 解决方案。

Curity 是一个现代化的身份和访问管理平台，围绕 Curity Identity Server 构建。这是一个基于标准的解决方案，旨在为大规模的应用、API 和数字服务提供安全的身份验证和授权。它支持 OAuth 2.0 和 OpenID Connect 等协议，以集中登录流程、执行细粒度的访问策略，并为人类用户和机器客户端（包括 API 和服务）颁发安全令牌。该平台设计灵活且可扩展，允许组织在云、混合或本地环境中部署，与现有系统集成，并提供安全、无缝的用户体验，而无需依赖定制构建的安全基础设施。

您的职业生涯大部分时间都在构建身份和 API 安全系统，从联合创立 Curity 到在云和如今 AI 兴起的过程中作为 CTO 领导公司。这段经历如何塑造了您的观点，即 AI 智能体应被视为一等数字身份，而不仅仅是另一款软件？

在我所经历的每一个技术领域，有一个问题不断重现。无论是云计算还是现在的 AI，如果软件代表一个人或另一个系统行事，那么你就面临一个身份问题。

随着智能体 AI 的大规模采用，这个问题变得更加复杂。它们的行为不再被严格脚本化，并且其运作具有企业前所未见的自主性。AI 智能体做出决策、调用 API 并在系统间链式执行操作——通常没有直接的人工监督。这种行为产生了与传统软件根本不同的身份和访问挑战。

将 AI 智能体视为一等数字身份是正确解决此问题的唯一方法。如果组织将它们仅仅视为另一个进程或服务账户，它们很快就会失去可见性和控制力——而这正是安全危机的根源。

许多企业对智能体 AI 感到兴奋，但仍停留在实验阶段。根据您在真实部署中的观察，阻碍组织安全扩展智能体的最常见身份和治理差距是什么？

大多数实验发生在孤立的沙箱中，忽略了规模化时会发生什么。在早期试点阶段，团队通常会给智能体提供宽泛的 API 密钥、共享凭证或全面的云权限，只是为了启动项目。

这种方法在智能体部署超出试点范围的那一刻就会崩溃。这是因为安全团队无法看到智能体访问了哪些数据、执行了哪些操作，或者它是否能够或已经超出了其预期范围；无论是意外还是恶意行为。这些盲点使得安全治理智能体变得不可能，这就是为什么许多组织难以超越试点阶段。

您曾主张严格的护栏对于智能体 AI 至关重要。在实践中，对于 AI 智能体而言，“良好”的身份设计是什么样的？公司通常在哪些地方出错？

良好的身份设计始于最小权限原则和与明确意图绑定的权限。每个 AI 智能体都应拥有自己的身份、范围狭窄的权限和明确定义的信任关系（允许其与哪些系统交互的明确规则）。从根本上说，访问应该是目的绑定、时间受限且易于撤销的。

公司出错的地方在于重用现有的服务账户，或者默认认为内部智能体是安全的。这种假设在现实世界的威胁面前站不住脚。恶意行为者积极寻找的正是这些薄弱环节，而当身份设计草率时，AI 智能体会极大地增加潜在的爆炸半径。

Curity 长期以来一直与 OAuth 和 OpenID Connect 等标准合作。开放身份标准对于使智能体 AI 在复杂的企业环境中实现互操作和安全有多关键？

开放标准绝对至关重要。企业已经运行着跨越云平台、SaaS 服务和内部 API 的复杂身份结构。智能体 AI 只会增加更多复杂性。

没有标准，每个智能体都会成为自己的集成点和永久的安全例外。有了 OAuth 和 OpenID Connect 这样的标准，智能体可以像任何其他工作负载一样进行身份验证、授权和审计。这是唯一能够在真实企业环境中促进安全扩展的方法。

非人类身份正变得越来越普遍，从服务账户到机器身份。从安全角度来看，是什么让 AI 智能体与以前的非人类身份有根本不同？

现代 AI 智能体与旧的非人类身份之间的关键区别在于自主性。传统的服务账户严格按其代码指示执行任务。AI 智能体则解释指令、调整其行为并执行从未被明确脚本化的操作——所有这些都增加了如果没有适当护栏时的潜在危险。

一个小的身份或访问错误可能迅速演变成灾难，因为智能体可以高速行动并跨越多个系统。从安全角度来看，这构成了重大风险。

审计追踪和基于身份的日志记录对于治理智能体 AI 有多重要，尤其是在受监管的行业？

审计追踪不应是“锦上添花”。它们需要从一开始就内置其中。在受监管的环境中，组织需要回答简单但关键的问题：这个智能体访问了什么、何时发生、以及谁授权的？

基于身份的日志记录是获得这种级别问责制的唯一可靠方法。它在事件响应中也起着关键作用。没有清晰的身份上下文，几乎不可能知道问题是来自行为不当的智能体、被入侵的身份，还是仅仅是一个糟糕的提示。

当组织在生产环境中部署权限过大或监控不善的 AI 智能体时，您看到了哪些现实世界中的风险？

一个常见的风险是静默数据聚合。一个权限过大的智能体可以从多个系统（客户记录、内部文档、日志）中提取敏感信息，然后通过提示、摘要或外部集成暴露这些数据。

另一个风险是拥有管理权限的智能体以机器速度进行重大更改，在短时间内造成的损害远超人类所能及。这可能包括修改云资源、禁用安全控制或在没有监督的情况下触发自动化工作流。

这些事件可能是恶意的，但也不一定。一个权限过大或监控不善的智能体可能只是基于过时或不正确的假设进行操作，在任何人注意到之前将错误放大到多个系统。

但是，从攻击者的角度来看，一个被入侵的智能体身份极具价值。它能够横向移动跨越 API 和服务，通常拥有任何人类用户都永远不会被授予的访问级别。如果没有强大的身份控制和监控，组织往往只有在造成实际损害后才发现这些故障。

对于从试点转向真实智能体部署的公司，哪些身份和访问决策应该尽早做出，以避免后期成本高昂的重新设计？

组织应尽早决定如何为智能体颁发身份、如何批准权限以及如何随时间审查访问，预先定义身份边界。

事后引入身份控制几乎总是问题重重。智能体通常使用共享凭证或宽泛角色深度嵌入到工作流中，因此在事后收紧访问会破坏系统所依赖的假设。这最终会导致工作流失败并削弱对该技术的信任。从一开始就设计适当的身份、范围和访问边界要便宜得多，更不用说安全得多了。

在推出智能体 AI 时，身份集成最常在何处成为瓶颈？哪些最佳实践有助于减少摩擦？

身份管理可能成为瓶颈，但仅当其被视为事后考虑时。团队首先专注于构建令人印象深刻的智能体能力，后来才意识到需要与 IAM 系统、API 网关和日志记录平台集成才能真正安全。

最佳方法是首先清晰理解并正确实施身份平台，然后设计智能体以适应这些平台。组织应重用现有标准和基础设施，而不是绕过它们；走这个捷径必然会在未来引发问题。当身份从一开始就内置其中时，它会加速部署而不是减慢速度。

对于希望采用智能体 AI 但担心治理和安全风险的安全和工程领导者，在规划路线图时，您会给出什么建议？

适当放慢脚步以打好基础。AI 智能体必须被视为身份，因此您需要应用与对人类相同的治理，并从一开始就坚持可见性。如果组织做到这一点，那么扩展智能体 AI 就变成了一项安全实践，而不是一次盲目且充满风险的信仰之跃。

Bạn có thể làm được điều đó không? Curity.