AI智能体已迅速从实验性工具转变为安全、工程、IT和运维等日常工作流的核心组件。最初作为个人生产力助手的工具——例如个人代码助手、聊天机器人和协同编程工具——现已演变为嵌入关键流程的、全组织共享的智能体。这些智能体能够跨多个系统编排工作流，例如：

• 人力资源智能体：根据HR系统更新，在IAM、SaaS应用、VPN和云平台中创建或注销账户。
• 变更管理智能体：验证变更请求、更新生产系统配置、在ServiceNow中记录审批信息，并在Confluence中更新文档。
• 客户支持智能体：从CRM获取客户背景信息、在计费系统中检查账户状态、触发后端服务修复，并更新支持工单。

为实现规模化价值，组织级AI智能体被设计为服务于多用户和多角色。与个人用户相比，它们被授予更广泛的访问权限，以便获取高效运作所需的工具和数据。

这些智能体的应用已带来切实的生产力提升：更快的分类处理、减少人工操作、简化运维流程。但这些早期成果伴随着隐性成本。随着AI智能体功能日益强大、集成度不断加深，它们也成为了访问中介。其宽泛的权限可能模糊实际访问者、访问内容及访问权限的边界。许多组织在追求速度与自动化的过程中，忽视了由此产生的新型访问风险。

组织级智能体的访问模型

组织级智能体通常被设计为跨越多资源运作，通过单一实现服务多用户、多角色和多工作流。这些智能体并非绑定于个人用户，而是作为共享资源，能够响应请求、自动化任务，并代表多用户跨系统协调操作。这种设计使智能体易于部署并具备组织级扩展性。

为实现无缝运作，智能体依赖共享服务账户、API密钥或OAuth授权来与交互系统进行身份验证。这些凭证通常长期有效且集中管理，使得智能体无需用户介入即可持续运行。为避免操作阻碍并确保智能体能处理广泛请求，其权限往往被宽泛授予，覆盖的系统、操作和数据范围通常远超单个用户所需。

尽管这种方法最大化了便利性与覆盖范围，但这些设计选择可能无意中创建出强大的访问中介，从而绕过传统的权限边界。

打破传统访问控制模型

组织级智能体通常以远宽于个人用户的权限运行，使其能够跨越多个系统和工作流。当用户与这些智能体交互时，他们不再直接访问系统，而是通过智能体代为执行请求。这些操作以智能体身份而非用户身份运行。这打破了传统访问控制模型——在传统模型中，权限是在用户层级实施的。权限有限的用户通过智能体间接触发操作或获取数据时，可能获得其直接访问未授权的资源。由于日志和审计记录将活动归因于智能体而非请求者，这种权限提升可能在缺乏清晰可见性、问责机制或策略执行的情况下发生。

组织级智能体可悄然绕过访问控制

智能体驱动的权限提升风险往往体现在细微的日常工作中，而非明显的滥用行为。例如，对财务系统访问权限有限的用户可能通过组织级AI智能体请求"总结客户表现"。拥有更宽权限的智能体从计费、CRM和财务平台提取数据，返回用户本无权直接查看的分析结果。

另一种场景中，没有生产环境访问权限的工程师要求AI智能体"修复部署问题"。智能体使用其提升后的凭证调查日志、修改生产环境配置并触发流水线重启。用户从未直接接触生产系统，但生产环境已因其请求而被更改。

这两种情况下都没有违反显式策略：智能体已获授权，请求看似合法，现有IAM控制在技术上也被执行。然而，由于授权是在智能体层级而非用户层级评估，访问控制实际上已被绕过，从而产生无意且通常不可见的权限提升。

传统访问控制在AI智能体时代的局限性

传统安全控制围绕人类用户和直接系统访问构建，难以适应智能体中介的工作流。IAM系统基于用户身份执行权限控制，但当操作由AI智能体执行时，授权评估针对的是智能体身份而非请求者身份。因此，用户层级的限制不再适用。日志和审计记录将活动归因于智能体身份，进一步加剧了问题，掩盖了动作发起者及其意图。在智能体介入的场景中，安全团队已无法有效执行最小权限原则、检测滥用行为或可靠归因操作意图，导致权限提升发生时无法触发传统控制机制。缺乏准确归因还会增加调查复杂性、延缓事件响应，并在安全事件中难以确定意图或影响范围。

揭示以智能体为中心的访问模型中的权限提升

Agentic AI本质上是身份问题，CISO需为结果负责

赞助商：Token Security

作者：Itamar Apelblat, Token Security CEO兼联合创始人

如今，如果您是一位首席信息安全官（CISO），Agentic AI可能会以一种令人不安的方式让您感到似曾相识。技术是新的，但模式并不陌生。业务领导者正大力推动在整个组织内部署AI智能体，而安全团队则被期望在确保安全的同时不拖慢任何进程。

这种紧张关系在云、SaaS和DevOps时代早已存在。每一次，身份都处于风险和解决方案的核心。

Agentic AI也不例外。它主要不是一个AI治理问题，而是一个身份问题，最终将由CISO对结果负责。

多年来，安全方案的设计一直围绕人类身份展开。员工和承包商身份集中管理，角色明确定义，访问权限定期审查，离职流程可预测。机器身份的出现颠覆了这一模式，它们数量激增并遍布云、流水线和SaaS平台。治理虽然后滞，但核心假设仍然成立。而AI智能体则彻底打破了这些假设。

AI智能体代表了一类新的身份。它们像人类一样有意图地行动，却又以机器的规模和持久性运作。它们天生是去中心化的，易于创建，并且能够在没有人类直接干预的情况下跨多个系统执行操作。

从身份角度看，这是可能的最复杂组合。这些智能体进行身份验证、授权并采取行动，但它们无法完全契合现有的身份模型。

这至关重要，因为身份仍然是导致安全漏洞最常见的根本原因。凭证被滥用、权限不断累积、所有权变得模糊。Agentic AI会同时放大所有这些风险。

许多智能体被授予广泛的访问权限，仅仅是为了快速运行。很少被审查，被停用的更是少之又少。

有些智能体在其创建者或所属项目早已不存在后，仍长期运行。对于攻击者而言，这些始终在线、权限过大的身份是理想的目标，这一点可以从OWASP的最新报告中得到印证。

传统的IAM和PAM工具并非为此现实而设计。它们假设用户是人，或者最多是可预测的工作负载。AI智能体不驻留在单一目录中，不遵循静态角色，也不局限于单一平台边界。

试图用传统的、以人为中心的控制措施来保护它们，会造成盲点和虚假的安全感。依赖AI平台供应商来解决这个问题同样危险。正如云提供商没有解决云安全问题一样，智能体平台也不会解决企业身份风险。

前进的方向不是限制创新，而是应用CISO们已经理解的准则：生命周期管理。只有当组织将身份视为一个从入职到离职的完整生命周期时，员工身份安全才变得可扩展。AI智能体需要同样的思路，并适应其速度和规模。

每个智能体都需要与身份提供商关联的明确所有权。其目的必须明确且可衡量。其访问权限应与实际行为相符，而非创建时的便利性。活动必须持续可见，以便及早发现权限漂移。当智能体闲置、项目结束或所有者离开时，访问权限必须自动撤销。没有这些控制措施，AI的采用最终将因其自身风险而崩溃。

CISO必须内化的一个关键转变是：智能体身份安全本质上是一个数据关联问题。您不能仅通过查看智能体本身来理解其风险。

真正的风险是由智能体能够触及的范围定义的。这包括它承担的云角色、访问的SaaS应用程序、可读取或修改的数据，以及它使用的下游身份。

保护Agentic AI需要跨智能体平台、身份提供商、基础设施、应用程序和数据层关联身份信号。

正是这种关联能力，使得CISO能够在审计、董事会审查和事件响应期间回答关键问题：谁有访问权限？为什么有？是否恰当？以及，是否还应继续存在？没有这种上下文，AI智能体将仍然不透明且难以治理。这里有一份CISO安全清单，有助于规划此类问题。

目前，许多组织正处于被动应对阶段，在智能体蔓延至生产环境后才开始发现。这个阶段将很快过去。下一阶段是预防。

身份管理必须前移到生命周期的更早阶段，即在智能体创建的时刻。构建者需要护栏，强制明确意图和范围，而不是为了方便而默认授予宽泛的权限。如果缺乏这种管理，CISO将继承风险并最终承担后果。

Agentic AI正成为企业运营方式中永久的一部分。问题不在于它是否会扩展，而在于它是否能安全地扩展。CISO将决定答案。如果智能体身份得不到管理，AI将引发安全漏洞、合规失败和高管的抵制，从而拖慢创新。

如果通过生命周期管理和可见性来治理智能体身份，AI将变得可持续、敏捷且安全。

成功的企业不会是那些对Agentic AI简单说“是”或“否”的企业。它们将是那些能够自信地说“是”的企业，因为它们很早就认识到，保护Agentic AI是身份管理的首要任务。

如果您已准备好自信地应对Agentic AI安全问题，Token可以为您提供帮助。

在此预约演示，我们将向您展示我们的平台在保障组织安全方面的独特之处。

本文由Token Security赞助并撰写。

发现站里有许多佬注册 aws 和完成任务得 200 刀乐的文章，但是这些刀乐怎么订阅 kiro pro + 没有一篇完整的教程。早上自己摸索了一下也算猜了一些坑，写一点自己的流程和踩过的坑与佬们分享

注册 aws 账号的过程请参考别的佬的文章，此处不赘述

首先注册完账号之后在控制台搜索 kiro，然后选择用户组

然后点击 add user，会发现咱们没有用户（我已经注册过了，假如第一次来是没有用户的），这时候点击页面里的链接转到 IAM

然后添加一个用户

在设置密码这里记得用默认的选项（就是用电子邮件设置用户密码的）
然后亚马逊就会给你发邮件，让你设置密码这一串的
最后回到 kiro 的控制台，add user，就能发现能搜出来咱们之前创建的账户了

最后就是下载 kiro 的 ide，然后选择最后一个选项登录（Sign in with AWS IAMldentity Center）
会出现一个让你填 start URL 的地方，复制 kiro 控制台此处的 URL 即可

（新人第一次写帖子，希望佬们多多包涵，如有错误希望佬们能指出）