MoEngage将25个团队、7个区域中的约400个私有REST API接入10个内部Agent，没有为每个团队单独搭建MCP服务器，也没有把API暴露到公网。
为什么不能把400个工具全塞给模型
大量工具定义会占满上下文，名称相似时模型容易选错；若每个团队维护MCP服务器，还会产生认证、网络、升级和策略不一致。更危险的是把租户身份或权限作为模型可填写参数，提示注入可能让Agent访问其他客户数据。
正确做法是平台统一注册工具，根据用户、Agent和任务只暴露允许的子集。身份由可信会话注入，模型不能覆盖。内部API继续留在私有VPC，通过受控出口访问。
OpenAPI到工具的自动流程
产品团队在OpenAPI规范中增加约定注解，持续集成检查规范、注册Gateway目标并应用Cedar策略。新增API不需要开发新的MCP服务，规范更新后自动同步。平台团队负责公共认证、网络、审计和客户端库。
工具描述要说明用途、必填参数、允许范围、返回结构和副作用。删除、群发、修改账户等操作单独分级，并需要二次确认。可参考Agent权限漏洞测试清单验证模型不能绕过规则。
区域和租户隔离怎么做
MoEngage在七个AWS区域部署Gateway，以满足数据驻留要求。请求根据租户所属区域路由，区域之间不能随意回源。Agent获得的是受限工具能力，不是底层网络访问权。
每次工具调用记录用户、租户、Agent、工具版本、参数摘要、结果码和策略决策。敏感字段脱敏，审计日志独立存储。策略拒绝应返回明确错误，让Agent停止或请求授权，而不是换参数反复尝试。
普通企业的渐进方案
先挑选10到20个只读API，统一OpenAPI质量和身份注入，验证工具发现、权限和日志。然后增加少量可逆写操作，使用幂等键和审批。最后才接触不可逆动作。
评估指标包括工具选择准确率、参数校验失败率、越权拦截、P95时延和新增API接入时间。平台化的目标是减少重复工程，同时让所有团队遵循同一安全边界。
落地结论
真正可用的AI系统必须同时满足任务有效、数据可控、成本可解释和失败可回退。建议先用真实且脱敏的小样本建立基线，再逐步开放工具与自动化权限；任何涉及生产修改、外部发送、医疗科研结论或资金的动作，都应保留人工审批和完整审计。
资料来源：AWS：MoEngage turned over 400 APIs into agent tools。本文依据公开资料重新整理，并结合工程实践给出操作建议；厂商公布的性能和案例数据不等同于独立第三方验证。
