越来越多的企业开始部署 AI 智能体（AI Agent），让它们自主理解目标、制定计划、调用工具、访问数据并直接执行操作。但科技媒体 TechRadar 撰稿人 Craig Hale 指出，这也带来了一类全新的攻击面：过去网络攻击主要利用人性弱点（如社会工程学骗局），而现在攻击者可以直接瞄准”机器的自主性”下手。智能体模糊了”软件”和”用户”的边界——它既不是传统程序，也不是人类员工，现有安全控制的很多假设因此不再成立。
好消息是，安全专家们的共识是：不需要推倒重来，只需把已有的安全原则——最小权限、强认证、职责分离——重新套用到智能体身上。Zendesk 首席安全官 Vinay Patel 在接受采访时给出了一套可落地的做法。
一、给每个智能体发”工牌”
不要把智能体当成藏在应用里的一个功能，而要像对待人类同事一样，给它一等公民的身份档案：
- 唯一的身份标识；
- 指定的负责人（相当于直属上级）；
- 明确的用途说明和具体权限清单；
- 完整的生命周期——创建日期、定期复审时间点、到期日。
Patel 特别强调设置到期日或定期重新认证的重要性：”否则智能体会变成比人类用户更难治理的长期访问通道。”员工离职、转岗时企业会回收权限，智能体也应一视同仁，避免积累大量被遗弃却仍握有数据访问权的”僵尸智能体”。
二、留好双份操作日志
智能体可以完全自主运行，也可以按任务受人指派。Patel 建议审计日志必须同时保留两个身份：发起或授权操作的人，以及实际执行操作的智能体。对完全自主的智能体，也要有日志将其关联到负责人、用途和已批准的策略。美国国家标准与技术研究院（NIST）的最新研究同样把”智能体行为、意图、数据来源和输出的可验证记录”列为优先事项。
三、按”零信任”思路管权限
云安全联盟（CSA）的一份报告认为，为静态应用和人类用户设计的传统身份与访问管理（IAM）已经跟不上了。报告建议：
- 智能体的凭证和权限应针对具体任务发放，短期有效、可随时吊销；
- 把”智能体被攻破”当作可能发生的事来设防；
- 通过最小权限、系统隔离和持续验证访问，控制事故影响范围。
四、问责机制要在部署前定好
Patel 提醒，出了事故再回头找责任人为时已晚：”问责必须在部署前定义，而不是事后重建。”企业需要提前厘清故障可能出在哪一环：用户的指令、智能体负责人的治理、开发者的设计、平台方的控制，还是企业自身的部署模式。最危险的情形是试点项目一路顺利，未经治理审查就直接转入生产环境——智能体一旦嵌入业务，再补治理就难了。
来源：TechRadar