前言
如果我们把“AgentOS”理解为一种为智能体长期运行、持续决策、主动调用资源而设计的操作系统，那么它会暴露出一个根本性矛盾：我们正在用为“被动程序”设计的安全模型，去约束“主动行为体”。
传统操作系统的安全模型，无论是 Unix 时代的“用户-组-其他”，还是后来的 RBAC、ACL，本质上都围绕一个假设展开：进程的行为是被代码预先决定的。权限的授予，是在执行前完成的；执行过程中，进程只是机械地行使这些权限。
而智能体并非如此。一个 Agent 进程会分析上下文、形成计划、权衡风险、选择路径，并在运行中不断改变“下一步要做什么”。在这种情况下，权限不再只是一个静态标签，而是直接影响 Agent 行为边界的认知约束条件。这使得 AgentOS 的安全模型，不再是一个外围系统，而是 Agent 能力设计的一部分。
一、为什么“最小权限原则”在 Agent 世界变得更难
在传统安全工程中，“最小权限原则”相对清晰：一个进程只被授予完成其功能所需的最少权限即可。但在 Agent 场景下，这个原则突然变得模糊。
Agent 的功能往往不是一个固定动作，而是一类目标。例如，“帮助用户完成报销流程”可能意味着读取邮件、访问内部系统、生成文档，甚至与其他 Agent 协作。在任务开始前，很难准确枚举所有必要操作。
未来解决此类问题，很多系统在实践中会选择一种危险但诱人的路径：提前授予一组“可能会用到”的广泛权限，然后寄希望于 Agent 的理性和 Prompt 约束不会越界。这种做法在短期内确实提升了成功率，但也在事实上放弃了最小权限原则。
更关键的是，这种权限膨胀并不是显式发生的，而是被包装成“提高智能体能力”的一部分，往往直到出现安全事故，问题才被正视。
二、传统“用户-组-其他”模型的根本失效点
Unix 的权限模型之所以经典，是因为它将安全问题简化为身份问题：你是谁，你属于哪个组，你能做什么。这种模型在面对长期稳定的服务进程时非常有效。
但在 AgentOS 中，进程的“身份
