《网络安全标准实践指南 — 智能体部署使用安全指引》在部署阶段多次强调一个原则：不要使用管理员权限运行智能体，只授予完成任务所需的最小权限，限制智能体可访问的目录，并尽可能避免开放公网访问。
这些要求看起来十分熟悉。对于从事网络安全的人来说，"最小权限原则（Least Privilege）"几乎是一个耳熟能详的概念。然而，如果仅仅把这些要求理解为传统网络安全最佳实践在Agent上的延伸，实际上低估了它们的重要意义。本文认为，这一章节真正反映的是权限治理对象正在发生根本性的变化。
过去二十多年，企业权限管理始终围绕着"人"展开。IAM（Identity and Access Management）负责管理用户身份，RBAC（Role-Based Access Control）根据岗位分配权限，PAM（Privileged Access Management）管理管理员账号。这些体系虽然形式不同，但都建立在同一个前提之上：真正做出决策并执行操作的是人，系统只是执行人的命令。
Agent改变了这一前提。当用户告诉Agent"帮我整理客户资料"时，他并不会告诉Agent先打开哪个系统、读取哪些文件、调用哪个API。用户只是给出了目标，而Agent则会自主规划整个执行过程：访问CRM系统、检索共享文档、分析合同、生成总结，甚至删除重复文件。因此，真正执行操作的主体，开始从人逐渐转向Agent。这也是为什么权限问题突然变得如此重要。
传统软件的行为基本是预先设计好的，而Agent拥有自主规划能力。权限越大，它能够采取的行动就越多；行动空间越大，不确定性也随之增加。一次模型幻觉、一次推理错误，甚至一次Prompt Injection攻击，都可能导致Agent执行原本不应该执行的操作。因此，在Agent时代，最小权限原则首先防范的，并不是攻击者，而是Agent自身的不确定性。
假设一个Agent因为理解错误，把"删除重复文件"理解成"删除所有文件"。如果它拥有整个服务器的管理员权限，后果可能是灾难性的；如果它只能访问一个指定的工作目录，那么即使发生错误，影响范围也会被限制在可控范围内。换句话说，最小权限并不是为了限制Agent完成任务，而是为了限制Agent在出现错误时能够造成的损害。
这种思想与近年来广泛采用的Zero Trust理念有着高度一致的内核。
Zero Trust最著名的一句话是："Never Trust, Always Verify（永不信任，持续验证）"。在传统IT系统中，它强调不要因为用户已经登录，就默认其所有后续操作都是可信的，而应持续验证每一次资源访问。很多人在讨论Agent治理时，很容易进一步得出一个结论：既然要持续验证，那么是不是Agent每执行一步操作，都需要人工点击一次"确认"？
答案显然是否定的。如果Agent调用一次API就需要人工确认一次，那么Agent带来的效率优势将荡然无存。事实上，Action-level Authorization（操作级授权）和Human Approval（人工审批）并不是同一个概念。Action-level Authorization强调的是，每一个操作都应该经过授权判断；而这个判断的主体并不一定是人，更多时候应该是系统预先设定好的安全策略。
例如，一个企业知识库Agent在回答问题时，可能需要依次访问内部文档、检索向量数据库、调用Embedding服务、生成总结。这些操作每天都会发生数千次，显然不可能每一步都等待人工审批。真正发生的过程是，策略引擎会自动判断这些操作是否符合既定规则，例如是否允许访问该知识库、是否允许调用指定模型、是否访问了授权范围之外的数据。对于符合策略的请求，系统自动放行，整个过程几乎不会被用户感知。
真正需要人工介入的，通常只有那些具有较高风险的操作，例如删除大量数据、向外部发送敏感文件、修改数据库记录、调整系统权限或者执行资金支付。这一点实际上也体现在《智能体部署使用安全指引》中，指南并没有要求所有操作都人工审批，而是提出要建立高风险操作清单，对重要操作进行二次确认。
因此，Agent时代真正发生变化的，并不是"所有操作都需要人批准"，而是授权的粒度发生了变化。
传统系统更多采用的是"登录一次、获得权限"的模式；而Agent治理正在逐渐转向"每一次关键操作，都根据实时策略判断是否允许执行"。授权开始从"登录时"前移到"操作时"，但绝大多数判断都由策略自动完成，而不是由人逐一审批。这背后其实体现的是一种更加成熟的风险治理思想。
企业并不是希望把所有控制都加到Agent身上，而是希望把控制集中在真正高风险的地方。低风险任务，例如读取公开知识、整理会议纪要、总结文档，可以完全自动完成；中风险任务，例如访问多个业务系统，可以由策略引擎自动判断是否符合预设规则；只有删除数据、修改权限、发送外部邮件、付款等高风险操作，才需要人工确认。
这种模式与银行风控十分相似。我们每天刷卡购买一杯咖啡，并不会触发人工审核；但如果突然发生一笔跨境大额转账，系统可能要求短信验证、指纹验证，甚至人工复核。治理的目标从来不是让所有交易都慢下来，而是把有限的控制资源集中在真正可能产生重大影响的场景。
国际上越来越多研究开始用两个概念区分这两种模式：Human-in-the-Loop和Human-on-the-Loop。前者意味着人在每一个关键决策中都参与审批；后者则意味着Agent自主完成绝大多数低风险任务，人更多负责制定规则、持续监督，并在异常情况或高风险场景下介入。本文认为，后者更符合Agent的发展方向。
另一个值得关注的变化是，传统RBAC模型正在逐渐暴露局限性。
RBAC假设每个人拥有一个相对稳定的岗位，例如财务访问ERP、销售访问CRM。但Agent的角色却是动态变化的。上午它可能负责回复邮件，下午整理合同，晚上分析销售数据，同一天内承担多个不同角色。它需要的权限随着任务不断变化，而不是固定绑定在某一个岗位上。
因此，仅依赖角色已经难以满足Agent治理需求。国际上越来越多企业开始探索基于属性（ABAC）或基于策略（PBAC）的访问控制模型，根据任务类型、数据敏感程度、时间、环境等因素动态决定Agent是否能够执行某项操作，而不是简单赋予一个固定角色。
回过头来看，《智能体部署使用安全指引》虽然没有直接使用Zero Trust、RBAC、ABAC等国际术语，但它实际上已经体现了这些成熟治理思想在Agent场景中的延伸。它讨论的已经不仅是权限配置，而是在回答一个更加根本的问题：当一个能够自主规划、自主调用工具、自主完成任务的软件开始成为企业里的"数字员工"时，我们应该如何重新设计权限体系？
本文认为，这也是未来Agent治理最值得关注的发展方向。今天企业讨论的仍然是如何管理用户权限，而未来真正需要管理的，很可能是如何管理拥有数字身份、自主能力和访问权限的Agent。届时，IAM管理的对象将不再只是员工账号，还包括Agent、Bot、服务账号等各种非人类身份（Non-Human Identity），权限治理也将从"管理用户"逐步演变为"管理数字劳动力"。
从这个意义上来说，最小权限原则并不是Agent时代的新原则，而是传统身份与访问管理理念在智能体时代的一次重新演绎。它的目标始终没有改变：不是阻止Agent完成工作，而是在Agent出现错误、受到攻击或超出预期时，把风险控制在企业可以接受的范围内。
而Agent权限治理的核心，并不是回答"Agent能访问什么"，而是回答"企业愿意将多大的决策权交给Agent"。权限的本质，其实是在定义Agent自主性的边界。
声明：本文来自数据合规与治理，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
