雅各布·伊德斯科格，Curity 的首席技术官 – 采访系列

雅各布·伊德斯科格 是一位身份专家和 Curity 的首席技术官。他大部分时间都花在与 API 和 Web 空间的安全解决方案上。 他曾与大型企业和初创公司合作，设计和实施 OAuth 和 OpenID Connect 解决方案。

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

您的大部分职业生涯都花在了构建身份和 API 安全系统上，从联合创立 Curity 到担任首席技术官，经历了云计算和现在的 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 部署的公司，为了避免以后昂贵的重新设计，应该在早期做出哪些身份和访问决策？

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

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

在部署具有代理能力的 AI 时，身份集成最常见的瓶颈在哪里，什么最佳实践可以减少摩擦？

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

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

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

放慢速度，直到基础正确。AI 代理必须被视为身份，并且您需要从一开始就应用相同的治理，并且需要从一开始就要求可见性。如果组织这样做，那么扩展具有代理能力的 AI 就会成为安全的练习，而不是盲目和鲁莽的信仰飞跃。

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