好消息是，安全专家们的共识是：不需要推倒重来，只需把已有的安全原则——最小权限、强认证、职责分离——重新套用到智能体身上。Zendesk 首席安全官 Vinay Patel 在接受采访时给出了一套可落地的做法。

一、给每个智能体发”工牌”

不要把智能体当成藏在应用里的一个功能，而要像对待人类同事一样，给它一等公民的身份档案：

1. 唯一的身份标识；
2. 指定的负责人（相当于直属上级）；
3. 明确的用途说明和具体权限清单；
4. 完整的生命周期——创建日期、定期复审时间点、到期日。

Patel 特别强调设置到期日或定期重新认证的重要性：”否则智能体会变成比人类用户更难治理的长期访问通道。”员工离职、转岗时企业会回收权限，智能体也应一视同仁，避免积累大量被遗弃却仍握有数据访问权的”僵尸智能体”。

二、留好双份操作日志

智能体可以完全自主运行，也可以按任务受人指派。Patel 建议审计日志必须同时保留两个身份：发起或授权操作的人，以及实际执行操作的智能体。对完全自主的智能体，也要有日志将其关联到负责人、用途和已批准的策略。美国国家标准与技术研究院（NIST）的最新研究同样把”智能体行为、意图、数据来源和输出的可验证记录”列为优先事项。

三、按”零信任”思路管权限

云安全联盟（CSA）的一份报告认为，为静态应用和人类用户设计的传统身份与访问管理（IAM）已经跟不上了。报告建议：

1. 智能体的凭证和权限应针对具体任务发放，短期有效、可随时吊销；
2. 把”智能体被攻破”当作可能发生的事来设防；
3. 通过最小权限、系统隔离和持续验证访问，控制事故影响范围。

四、问责机制要在部署前定好

Patel 提醒，出了事故再回头找责任人为时已晚：”问责必须在部署前定义，而不是事后重建。”企业需要提前厘清故障可能出在哪一环：用户的指令、智能体负责人的治理、开发者的设计、平台方的控制，还是企业自身的部署模式。最危险的情形是试点项目一路顺利，未经治理审查就直接转入生产环境——智能体一旦嵌入业务，再补治理就难了。

来源：TechRadar