Jacob Ideskog，Curity 的 CTO – 采访系列

Jacob Ideskog 是一位身份专家和 Curity 的 CTO。他大部分时间都花在 API 和 Web 空间的安全解决方案上。他曾经为大型企业和小型初创公司设计和实施过 OAuth 和 OpenID Connect 解决方案。

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

您的大部分职业生涯都在构建身份和 API 安全系统，从共同创立 Curity 到领导它作为 CTO，经历了云计算和现在 AI 的崛起。这段旅程如何塑造了您对 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 代理和旧的非人类身份（NHIs）之间的关键区别在于自治。传统的服务帐户只做其代码告诉它做的事情，严格绑定到其任务。AI 代理解释指令，适应其行为，并采取从未明确编写的操作——所有这些都增加了如果没有适当的防护措施，就会带来危险。

一个小的身份或访问错误可能很快就会变成一场灾难，因为代理可以快速地跨多个系统运行。从安全角度来看，这带来了重大风险。”

审计跟踪和基于身份的日志记录对于治理代理 AI，特别是在受监管的行业中，多重要？

审计跟踪不应该是“很好”的功能。它们需要从一开始就构建。 在受监管的环境中，组织被要求回答简单但关键的问题：代理访问了什么，何时发生的，以及谁授权的？

基于身份的日志记录是获得这种责任感的唯一可靠方法。它还在事件响应中发挥着关键作用。没有明确的身份背景，很难知道问题是由行为不端的代理、泄露的身份还是简单的提示引起的。

当组织在生产中部署过度特权或监控不力的 AI 代理时，您看到哪些现实风险？

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

另一个风险是具有管理访问权限的代理在机器速度下进行重大更改，可能会在短时间内造成远比人类更大的损害。这可能包括修改云资源、禁用安全控制或触发自动工作流，而无需监督。

这些事件可能是恶意的，但它们不一定是恶意的。过度特权或监控不力的代理可能只是在运行过时或不正确的假设，放大多个系统中的错误，然后有人才会注意到。

但是，从攻击者的角度来看，泄露的代理身份非常有价值。它可以实现跨 API 和服务的横向移动，通常具有人类用户永远不会被授予的访问权限。没有强大的身份控制和监控，组织通常只会在真正造成损害后才发现这些故障。”

对于从试点转向真正的代理部署的公司，为了避免以后进行昂贵的重新设计，应该提前做出哪些身份和访问决策？

组织应该提前决定代理如何被颁发身份、如何批准权限以及如何随时间审查访问权限，定义身份边界。

在事后引入身份控制几乎总是有问题的。代理通常使用共享凭据或广泛的角色深深地嵌入工作流中，因此事后收紧访问权限会破坏系统依赖的假设。这最终会导致工作流失败并破坏对技术的信任。从一开始设计适当的身份、范围和访问边界要便宜得多，也更安全。

在推出代理 AI 时，身份集成在哪里最常成为瓶颈，什么最佳实践可以帮助减少摩擦？

身份管理可以成为瓶颈，但仅当它被视为事后补充时。团队首先专注于构建令人印象深刻的代理功能，稍后才意识到需要将其与 IAM 系统、API 网关和日志平台集成，以确保安全。

最佳方法是首先明确理解和正确实施身份平台，然后设计代理以适应其中。组织应该重用现有的标准和基础设施，而不是绕过它们；削减这个角落最终会在以后引起问题。当身份从一开始就被构建时，它会加速部署，而不是减慢速度。

对于希望采用代理 AI 但担心治理和风险的安全和工程领导者，您会给出什么建议，当他们规划自己的路线图时？

放慢速度，只要足以把基础知识弄对。AI 代理必须被视为身份，并且您需要像对待人类一样对其施加相同的治理，并从一开始就要求可见性。如果一个组织这样做，那么扩展代理 AI 就会成为一个安全的练习，而不是盲目和鲁莽的飞跃。

感谢这次精彩的采访，希望了解更多的读者可以访问 Curity。