先讲一个我最近遇到的真实场景。一个 10 人团队开始把 AI Agent 引入日常工作写周报、查数据、生成代码片段、整理会议纪要。前三天各自在本地跑非常顺利。第四天有人把调试好的 Agent 配置发到了群里大家开始复用同一个 Agent。效率确实上来了但问题也接踵而来——一个只有只读权限的实习生让共享 Agent 帮忙“改一下线上配置”Agent 真的执行了而且改成功了。这不是模型不够聪明的锅。这是权限边界没有设计好。最近在 Hacker News 上看到一个项目标题写得很直白AgentConnect, shared agents with separate permissions。翻译过来就是“共享 Agent但权限分离”。这个标题没有提模型多强、推理多快单刀直入地指向了一个很多人还没认真面对的问题当 Agent 从个人工具变成团队共享资源真正困难的地方根本不是“怎么让 Agent 干活”而是“怎么让 Agent 在每个人的边界之内干活”。这篇文章想把这个命题拆开讲清楚共享 Agent 的权限问题到底出在哪里、一个可落地的权限模型长什么样、落地时最容易踩哪些坑以及它为什么会成为团队协作下一阶段的核心问题。1. 共享 Agent真正难的不是“共享”而是“各开各的权限”1.1 共享是人的本能权限是工程的反抗你先体会一下这个矛盾任何好用的工具团队都会自然走向共享。Agent 也不例外。一个人调试好的工作流如果只能自己用价值是 1如果十个人都能用价值是 10。这是人性驱动的结果挡不住。但权限这件事恰恰是给“共享”踩刹车。它的本质是回答一个问题谁能用、能用到什么程度、碰了什么要留下记录。如果 Agent 只是一个聊天机器人问题不大。但今天的 Agent 已经能操作文件、访问数据库、调用外部 API、运行代码甚至执行部署流程。当你能让一个 Agent 替你“做事情”的时候它就不再只是一个信息工具而是一个拥有执行力的数字同事。一个拥有执行力的数字同事如果你把它的能力开放给所有人那就是在团队里同时放了很多个“谁的话都听”的实习生。你说危险不危险。1.2 Agent 权限和普通账号权限完全是两回事很多团队的误区是我们已经有 SSO 了有 RBAC 了再给 Agent 加个账号不就行了不够。普通账号权限管的是“人能不能访问某资源”但 Agent 权限要管的是“人让 Agent 去访问某个资源这个请求允不允许”。差别在哪普通权限人点击按钮系统判断这个人有没有权利。Agent 权限人对 Agent 说“帮我做这个”Agent 自主规划步骤、调用工具、产生副作用。系统需要判断的是这个人的授权范围和这个 Agent 的能力范围交集在哪里。如果 Agent 的能力范围大于调用者的授权范围那么共享 Agent 本身就成了一条提权路径。用户本来没有权限操作的资源通过请求一个握有高权限工具的 Agent就间接拿到了访问权。这在安全领域叫权限提升只不过这次提权不是通过漏洞而是通过设计缺陷。所以 AgentConnect 这个标题里的 “separate permissions” 才是重点。“共享”是产品形态“权限分离”才是安全底线。2. 把共享 Agent 当成一个多租户系统来设计2.1 从单用户到多用户问题全面升级单用户场景下Agent 不需要考虑身份问题。我自己创建的 Agent我调用的工具我访问的资源天然是一体的。可一旦 Agent 被共享它就从“我的助手”变成了“大家的前台”。这个前台要面对多个用户、处理不同权限的请求、访问不同密级的资源。本质上你已经实现了一个微型多租户系统只是很多人还没有意识到。多租户系统要解决的三个基本问题共享 Agent 全都有身份隔离谁是谁能不能分清。数据隔离A 用户的数据不能泄漏给 B 用户。操作隔离A 用户不能触发超出其权限的操作。在这三个问题的地基之上才谈得上 Agent 能力共享。2.2 权限分离需要管住哪几层从工程实现的角度看一个共享 Agent 的权限体系至少要覆盖以下四层层级要控制什么典型问题用户身份层谁能调用这个 Agent匿名访问、越权调用Agent 能力层这个 Agent 能使用哪些工具Agent 工具列表过宽资源访问层用户和 Agent 能碰哪些数据、文件、外部系统只读用户借 Agent 写数据操作审计层谁在什么时间让 Agent 做了什么无法追溯、无法定责最关键的是第二层和第三层的交集。一个 Agent 可能有 10 个工具但某个用户只被允许使用其中 2 个。如果系统只检查了“这个用户能否调用这个 Agent”而没有检查“这一次调用用到哪个工具”那权限就失控了。我见过一个真实例子一个团队把数据分析 Agent 共享给全部门Agent 配置了读数据库、写报告、发邮件的权限。结果一个实习生让它“把这周的数据汇总发给我”Agent 直接读了数据库并发了邮件。本来数据是有访问控制的但 Agent 的高权限绕过了这层控制——因为系统的权限检查停在了“用户可调用 Agent”这一层没有继续往下走到“用户不可借 Agent 触达邮件系统”。这也是为什么任何共享 Agent 的权限模型都应该把检查粒度细化到具体的工具和资源而不是只停留在“能不能调用”这个粗粒度上。3. 一个可落地的共享 Agent 权限模型3.1 最小权限模型不是“用户能做什么”而是“交集”假设你要设计一个类似 AgentConnect 的系统或者干脆自己实现一个内部分享 Agent 的平台我建议从一个比较清晰的最小模型开始。这个模型有三个实体用户发起请求的人有自己的资源授权范围。Agent执行任务的配置单元有自己绑定的工具集和提示词。工具/资源Agent 可以调用的外部能力比如文件系统、数据库、API、代码执行器。一次请求的最终权限由两个范围的交集决定用户的资源范围这个用户被允许访问什么。Agent 的工具范围这个 Agent 被配置了哪些工具。交集中的部分才允许执行。谁的权限小就听谁的。这就是最小权限原则在 Agent 场景下的直接体现。用一个配置示例来说明{ agents: { data-analyzer: { allowed_users: [alice, bob], tools: [read_file, run_sql, write_report, send_email], resource_rules: { run_sql: { databases: [analytics], readonly: true } } } }, users: { alice: { resource_scopes: [analytics, reports] }, bob: { resource_scopes: [analytics] } } }在这个模型里Alice 可以调用>def can_execute(user, agent, tool, resource): if user.id not in agent.allowed_users: return False, user cannot access this agent if tool.name not in agent.tools: return False, agent has no such tool if resource.id not in user.resource_scopes: return False, user has no access to this resource if tool.name in user.denied_tools: return False, user is denied this tool return True, ok注意这个检查发生在Agent 每次调用工具之前而不是 Agent 开始执行之前。原因是 Agent 的执行过程是动态规划的它可能一开始只计划读文件后面决定写文件。如果系统只在任务开始时做一次权限检查那么中途产生的越权操作就完全漏掉了。经验不要只做“任务级授权”要做“工具调用级授权”。Agent 的执行链路是动态的权限检查必须跟着每一步走。3.3 什么情况下必须无条件拒绝有些操作在任何情况下都不应该被允许通过共享 Agent 执行除非你有单独的强审批流。这些操作通常包括删除生产环境数据。修改权限配置本身。向外部发送高敏感数据。执行未经沙箱化的任意代码。跨租户访问其他用户的数据。这些规则最好是全局的、硬编码的不受单个 Agent 配置影响。因为 Agent 本身的配置是允许被修改的如果权限规则存在 Agent 配置里那么一个握有修改权限的用户可以直接把规则改掉。这等于让运动员自己当裁判。正确做法是把“硬性安全规则”和“可配置的权限策略”分开。硬性规则写在系统内核里任何 Agent、任何用户都不能绕过可配置策略才下放到团队或项目级别。4. 真正落地时最容易踩的五个坑4.1 权限检查放错了位置最常见的坑是把权限检查放在 Agent 开始执行前后面就完全放开。今天的 Agent 不是“输入一条指令、输出一个结果”的简单函数。它内部会经历规划、调用工具、观察结果、再次规划、再次调用工具的多轮循环。如果你只在最开始检查一次那么后面每一轮工具调用都处于失控状态。正确的做法是在 Agent 的每次工具调用入口都做拦截。另外要留意一种隐蔽情况Agent 生成了代码然后调用代码执行器来运行。这时候真正产生副作用的不是 Agent 直接调用的 API而是被执行的代码。如果系统只检查了“调用代码执行器”这个动作没有检查“代码执行器内部要访问什么资源”权限一样会被绕过。4.2 中间产物没有隔离两个用户共享同一个 AgentAgent 在执行过程中会产生临时文件、缓存、中间报告、日志。如果这些中间产物存放在同一个共享目录那么 A 用户的敏感数据很有可能通过文件系统泄漏给 B 用户。更隐蔽的泄漏路径是对话历史。如果 Agent 自带多轮对话记忆而 A 用户在一个会话里上传了敏感的 CSV 文件B 用户又接续了同一个会话那么 B 就相当于通过“会话共享”读到了 A 的数据。所以共享 Agent 的数据隔离必须覆盖四个方向输入数据、输出结果、中间文件、会话上下文。缺一个都可能出问题。4.3 日志只记结果不记链路很多权限问题不是当场爆发的而是事后很久才发现某个数据被外部拿到了某个配置被人改了。这时候如果没有完整的操作链路日志排查会变得极为困难。你需要记录的不仅是“谁用了哪个 Agent”而是用户 ID。Agent ID。会话 ID。每次工具调用的时间、参数、返回结果。被访问的资源标识。权限检查的结果通过还是拒绝。如果是拒绝是哪个规则拦截的。有了这套日志你才能在出现问题时回答“这个用户是怎么让这个 Agent 拿到这份数据的”4.4 权限策略写死了Agent 一升级就失效另一个常见问题是权限策略和 Agent 版本没有关联。今天你给 Agent 配了 5 个工具并给每个工具都定义了精细的资源范围。过两周有人更新了 Agent 配置新增了一个web_search工具但资源范围没有同步更新。结果所有用户都能通过新工具访问外部网络甚至把内部数据发送出去。建议把权限策略与 Agent 版本绑定。每次 Agent 配置变更都走一次权限评审。如果评审不通过新版本不允许发布到共享环境。4.5 只考虑权限没考虑配额和成本共享 Agent 还有一个容易被忽略的问题成本边界。Agent 执行过程中会消耗 Token、消耗 API 调用额度、可能触发昂贵的外部服务调用。如果不对每个用户的调用配额做限制一个不限量的共享 Agent 可能在几天内烧掉整个团队的预算。可以给用户或团队设置调用上限、单次任务时长上限、外部 API 调用次数上限。这虽然不是权限问题但它是共享 Agent 能否长期维持的另一个前提。5. 从“能用”到“敢用”还要补这些工程能力5.1 审计与追溯前面已经提过日志这里再往深说一层审计不是简单地记录而是能够支撑“事后回放”。当有人质疑一次 Agent 操作是否合规时你最好能把那次任务的完整执行过程重放出来用户给了什么指令Agent 做了哪些规划调用了哪些工具每一步的输入输出是什么。只有到这一步审计才算是真正可用。要做到这一点光有应用层日志不够。最好把 Agent 每次规划的内部思考也记录在案否则你只能看到“它调用了删除接口”但你不知道它为什么调用。5.2 高风险操作的动态审批有些操作在“这个用户 这个 Agent 这个资源”的静态权限检查中可能没问题但风险仍然很高。比如删除一个文件或者给外部系统发一封包含数据的邮件。对于这类操作仅靠静态规则是不够的。更稳妥的方案是引入审批流当 Agent 执行到高风险工具时把请求挂起通知有审批权限的人确认通过后才继续执行。这也是共享 Agent 和本地单用户 Agent 最大的体验差异。本地 Agent 不需要中间审批你完全信任自己。但共享 Agent 面对的是不同权限等级的同事中间审批不是阻碍效率而是保护所有人。5.3 策略的可测试性权限策略本身也是代码。它是代码就应该被测试。建议在 CI 里加入权限策略的测试用例。比如“用户 A 调用 Agent X 读取数据库” → 期望通过。“用户 A 调用 Agent X 写入数据库” → 期望拒绝。“用户 B 调用 Agent X 读取数据库” → 期望拒绝。“用户 A 查看 Agent X 的输出中包含用户 B 的数据” → 期望隔离生效。把这些测试用例固化下来每次权限配置变更都跑一遍能大大减少“权限策略改崩了但没人发现”的情况。5.4 快速终止机制最后一个是保命能力当某个 Agent 失控时你能不能立刻终止它。这个能力看起来基础但很多早期系统都没有。Agent 执行是异步的、多步的如果用户在界面上点了一个“停止”按钮但背后已经在跑的子任务没有真正被取消那么用户以为停了实际上副作用还在继续。真正的终止机制应该做到中断当前任务、取消已排队但未开始的子任务、清理临时文件、释放资源。最好还要能区分“正常停止”和“强制终止”后者要触发安全通知。6. 这类方案的适用边界先想清楚你的场景6.1 什么情况下你真正需要“共享 Agent 权限分离”我建议用这几个问题来判断你的 Agent 是否会访问敏感数据或触发外部副作用你的团队是否有不同权限等级的人共用同一套 Agent你是否需要在事后回答“这个 Agent 帮谁做了什么事”你的 Agent 是否会执行写操作而不仅仅是输出文本只要这四个问题里有两个打“是”就值得上共享权限方案。如果你的 Agent 只是给自己写摘要、做翻译那完全不需要搞这么重。6.2 什么情况下先不要上这套方案反过来如果你的场景是单人使用。纯实验性质数据不敏感。Agent 只读不写不触发外部操作。团队很小信任度极高且约定俗成不用审计。那你可以先不做权限体系先把 Agent 跑起来验证它在业务上有没有价值。价值不明确之前引入复杂的权限模型只会拖慢迭代。6.3 从轻量起步的路径即使你判断需要权限体系也不必一步到位。我的建议是分三阶段走阶段一单 Agent 单用户。跑通任务本身确认业务价值。阶段二单 Agent 多用户只做基础访问控制。把用户身份接进来限制谁能调用全平台只给统一的工具集先不搞精细化资源隔离。阶段三多 Agent 多用户做精细化权限。每个 Agent 有独立工具集每个用户有独立资源范围工具调用级授权、审计、审批流全部到位。AgentConnect 这类项目本质上就是帮你把阶段二和阶段三的公共部分标准化。具体怎么配置要结合你们团队的模型、工具、数据流来定。7. 回到最底层的经验共享 Agent 这个方向未来一定会成为团队协作的标配。原因也很简单单个 Agent 的能力再强在一个团队里也只是信息孤岛。只有当 Agent 可以被安全地共享、被多个人按照自己的权限使用它才真正从“工具”变成了“基础设施”。但基础设施的属性是你可以做得不完美但必须可靠。你可以没有最炫的提示词但你不能让一个只读用户通过共享 Agent 写坏生产数据。你可以没有最多的工具集成但你不能让 A 用户的数据出现在 B 用户的会话里。AgentConnect 这个标题提醒我的恰好是这一切的起点共享是产品能力权限分离是工程底线。两者都要有缺一个Agent 就只适合留在自己的电脑里自娱自乐。如果你正在团队里推广共享 Agent我建议你从最小的事情做起先给每个 Agent 建一份权限清单明确谁能调用、能调哪些工具、能碰哪些资源然后跑一条最危险的任务路径看看系统在你预想的最坏情况下会不会拦住。能拦住再谈扩大共享范围。拦不住就先别放开。