AI Agent接入MCP服务器≠拥有全部工具权限

很多团队以为AI agent只要能连上MCP server，就能调用上面所有工具。Doordash的实践给出了相反答案：Gateway会逐个请求做权限校验，agent能进服务器，不代表能碰每个工具。

Gateway的两个核心问题：认证与授权

据YouTube频道lalaschool的分析，Gateway在每次工具调用时都要回答两个问题。

Authentication（认证） 解决"谁在调用"。调用方可能是一个普通用户、一个后台服务，也可能是代表某个用户行动的agent。身份不同，后续能做的事完全不同。

Authorization（授权） 解决"这个调用方被允许做什么"。同一个服务器上可能同时挂着只读的查询工具和破坏力极强的admin工具，能搜索repo并不意味着能删库。

这两个问题分开处理是关键。认证只确认身份，授权才决定边界，混在一起做就容易出现"连上了就全放行"的漏洞。

MCP（Model Context Protocol）是Anthropic提出的一套开放协议，用于让AI模型或agent以标准化方式连接外部工具和数据源。MCP server即按照该协议暴露工具接口的服务端，agent通过MCP client发起连接并调用具体工具。协议本身解决了"如何发现和调用工具"的互操作问题，但并未规定细粒度的访问控制——连接建立只代表通信链路可用，具体某个工具能否被某次调用执行，仍需由上层基础设施判断。这正是文中Gateway存在的意义：在协议层之上补上认证与授权逻辑。

策略引擎要看四层上下文

Gateway的策略判断不只看调用方是谁，还会综合多个维度：是哪个agent、代表哪个用户、调用哪个工具、请求处在什么环境。

权限粒度还细到读写之分。agent可以替用户读取issue详情，但涉及admin的写操作就会被拦下。这种区分让agent在只读场景下保持高效，又不会因为一次误调用造成数据破坏。

有些workflow是以团队身份运行的，这类自动化流程有稳定的权限边界；而某个人的单独操作，则需要本人明确授权。身份不是静态标签，而是跟着请求走的上下文。

策略引擎（policy engine）是权限系统中的决策组件，负责根据一组规则对每次请求输出允许或拒绝的判定。它通常与执行点分离：执行点负责拦截请求并向引擎询问，引擎只做判断、不直接操作资源。这种分离使策略可以集中维护、独立于业务代码演进。文中Gateway的策略引擎接收agent身份、代表用户、目标工具和运行环境等上下文作为输入，结合读写级别等属性得出决策，属于典型的上下文感知授权（context-aware authorization）模式。

身份要跟着请求一路走到底

据lalaschool的拆解，调用方身份会随请求穿越整个链路：从路由转发、usage记录，一直到最终执行的动作。

这样做的价值在于可追溯——事后能查清某个动作是谁发起的，是哪个agent代表哪个用户做的。对于需要审计的企业场景，这是权限系统能否落地的前提。

身份透传（identity propagation）指调用方身份信息在服务间调用链中被完整携带，而非在某一跳被丢弃或替换为服务自身身份。常见实现方式包括在请求头或令牌中附加用户与agent标识、使用可委托的短期凭证，以及在日志与追踪系统中记录身份字段。若身份在中途丢失，下游只能看到"某个服务在调用"，审计时就无法回答"是谁发起"，也无法做基于原始调用方的权限复核。因此身份透传是可追溯性与最小权限原则落地的基础设施前提。

集中式网关的三个实际收益

把权限决策收敛到Gateway，带来三方面好处，视频中都有提及。

改权限或收回权限只改一处。 分散在各处的权限逻辑最难维护，一旦人员或策略变动，容易漏改。

Dev agent不必把安全规则塞进prompt。 靠提示词约束agent行为既脆弱又不可验证，把安全交给基础设施层更可靠。

工具所有者不必重写授权逻辑。 每个工具各自实现一套权限判断，重复劳动且容易不一致，统一到Gateway后工具侧只需关注功能本身。

对agent开发的启示

视频结尾抛出的问题值得每个做agent的团队自查：你的agent现在拿着什么权限？

至少可以从三点入手：认证认到人（或服务、agent）这一层；授权下沉到单个工具而不是整个服务器；身份信息随请求透传，保证动作可归因。

MCP让工具接入变简单了，但接入只是起点。真正的安全边界在Gateway的逐次校验里，而不是在"连接成功"那一刻。

（本文基于YouTube频道lalaschool的视频内容整理分析。）