容器隔离不够用了：AI 智能体开始要"最小权限"，福建企业上 Agent 前先划这条线
一、先说结论
InfoQ 2026年11月13日报道，Edera 推出了一套"对象能力受限"的权限模型，把控制点放在虚拟机监控器层，核心主张只有一句话：AI 智能体做事的权限，和它用的凭证，必须分开。
现在的现实是，越来越多企业在生产环境里跑自主编码智能体和外部工具集成，习惯性地把敏感的 API 令牌、云密钥、管理员凭证直接塞进执行环境（环境变量、配置文件）。这在传统安全模型里是常规操作，但一旦被大模型驱动的智能体拿下——比如遭遇提示注入或供应链投毒——攻击者往往能直接提取这些令牌，然后在内部系统间横向移动。
Edera 的做法是：智能体不持有密钥，只持有被严格限定范围的能力。比如一个 AI 编码助手可以在不拿到个人访问令牌的情况下，被授予修改某一个指定 GitHub 仓库的权限；一旦被入侵，影响范围被收敛在这一件事上，而不是整个环境。官方披露的落地组件包括 capcurl（无凭证 API 访问，授权请求经隔离代理转发）、capsudo（限定作用域的命令执行，无需长期 root 权限）以及 SPIFFE/SPIRE 工作负载身份（密码学校验身份与双向 TLS，不依赖长期静态密钥）。
对福建企业的直接含义：上 AI 智能体，真正的分水岭不再是"模型聪不聪明"，而是"它被攻破之后能造成多大损失"。这条线现在可以画，而且不用等自己被攻击一次。
二、这次到底变了什么
| 变化点 | 官方披露内容 | 对中小企业意味着什么 |
|---|---|---|
| 控制点位置 | 直接在虚拟机监控器层实施细粒度对象能力控制 | 权限不再靠应用层自觉，而是由运行时强制执行 |
| 权限粒度 | 可细化到单资源单操作，例如仅限某个仓库的 push | 每个 Agent 任务可单独授权，用完即止 |
| 凭证处理 | 操作权限与底层凭证分离，密钥不进工作负载 | 密钥泄露面从"整个 Agent 环境"缩到几乎没有 |
| 身份体系 | 集成 SPIFFE 与 SPIRE，工作负载身份可密码学验证，建立双向 TLS | 免维护长期密钥这一类高危资产 |
| MCP 服务器 | 在基础设施层定义明确对象能力，限制到特定资源与命令范围 | 连接数据库和办公系统的 MCP 服务端不再等于敞开大门 |
| 现状与节奏 | 限定作用域的命令执行与工作负载身份已发布；基于凭证代理的 API 访问与编排器深度集成，属 Project Lunchbox 计划后续推出 | 现在可借鉴的是思路与权限模型，不是立刻能装一套完整产品 |
对照一个企业侧的事实：真正有价值的资产是代码库、客户数据、账号权限——"一个 Agent 拿着你的管理员密钥"，比任何市场风险都来得直接。
三、福建企业真正能用在哪
- AI 编码助手的接入规范。福建的软件外包与数字化交付团队已在用 AI 辅助写代码。传统做法是把自己个人 access token 塞进插件和脚本方便调用，代价是任何一次误操作或恶意依赖都可能波及仓库与流水线。正确姿势是按仓库、按分支、按操作类型分开授权。
- 接了第三方 API 的业务系统。客服机器人、发票识别、内容生成这类应用普遍要调外部服务。密钥下沉到执行环境是通病，改造方向是让密钥只存在于服务端一侧，Agent 只拿到"能调这个接口的凭证"。
- MCP 服务器接入的企业工具。MCP 服务器连接大模型与企业数据库、办公系统，是价值高、防护薄的一层。做内部工具接入时，先在基础设施层写清它允许访问哪些资源、允许执行哪些命令，再谈功能。
- RPA 与自动化脚本的权限收敛。很多企业的报表自动化、巡检脚本跑在共享服务器上，用的是高权限账号。限定作用域的执行能力正好对应这类"活儿多、权限大"的场景。
- 给合规留证据。等保、数据合规审查越来越常问到"AI 访问了什么资源、什么时候访问的"。按能力授权并留下身份校验记录，本身就是可交付的审计材料。
四、可照做的四步
- 第一步：把智能体用到的凭证列一张表。逐条写清楚：哪个 Agent、哪个任务、什么环境、用的是谁的权限、有效期到什么时候。
- 第二步：按最小权限重新授权。能只读就不给写，能限单个仓库就不给整个组织，能给单次任务就不给长期令牌。
- 第三步：把高权限操作挪出 Agent 的手。发布上线、删库改配置这类动作改为人工确认触发，Agent 只负责准备命令和给理由。
- 第四步：把"被攻破"当成必测场景。在测试环境模拟一次提示注入或恶意依赖注入，看 Agent 到底能碰到哪些东西——测出来的边界才是真边界。
五、三个坑
- 坑一：以为上了 Agent 就等于上了防护。很多企业的 AI 落地停在"功能能跑"，安全侧仍是"给个大账号"。功能上线和权限收敛之间，往往隔着一整套没人排期的改造。
- 坑二：把权限收得太紧，Agent 变成摆设。权限拆到无法完成任务的粒度，Agent 每一步都要等人工，反而比原来更贵更慢。合理目标是"任务能跑完，出事有边界"。
- 坑三：只做功能不做清单。没有那张凭证清单，就没人说得清系统里到底有多少把钥匙在流转，也没人为后续收敛排期负责。
六、什么时候上、什么时候别上
适合现在上：正在做智能体试点、或者已接入外部工具但还没做权限梳理的项目，现在正是分界线最清晰的时候，成本最低。已经严格按最小权限运行、按单任务临时授权的系统，不需要为此重构。
不建议现在上：为了"看起来更安全"就推翻现有可用流程、重新搭一套 Agent 平台。安全能力要长在业务里，不是替代业务。
智能体时代的权限管理，本质上还是那件最朴素的事：把钥匙发得刚刚好，让智能体只拿工具，不拿钥匙。