Stripe让Agent直接查账：如何不把数据库底裤露给大模型

　　本文是Stripe把支付分析数据开放给智能体的工程案例分析：三条接入路径（含MCP）让agent直接做经营分析，三百张以上表连同该用什么口径一起给出去，每条查询都能回看底层语句；同一台服务器上的资金类工具则挂着人工确认，批准之后还要agent自己重试才执行。这套工具调用与核验的分层方式，比它开放了哪些数据更值得看，也是把智能报表交给机器时最该先定下来的部分。 　　全文约5500字，梳理数据模型、密钥范围与确认闸门三层各自解决的问题和留下的缺口；重点速读约7分钟，完整精读建议预留14分钟以上。

为什么把生产库直接交给模型，最先出事的不是权限

　　把支付数据接进大模型，多数团队的第一个动作是收紧权限：只读账号、限定IP、脱敏字段、加审计日志。这些都对，但它们挡的不是最先出问题的那一处。文中说的「把底裤露出去」，指的正是跳过这些前置设计，直接把库和权限一起交给模型。

　　先想清楚一次查询会怎么走。用户问「上个季度我们为什么收入掉了」，agent需要知道三件事：用哪张表、这张表里收入指的是什么、算出来的数字能不能被人复核。三件事里没有一件是权限问题。权限只决定agent能不能进这间屋子，进了屋子之后它照样可能拿错文件。

　　拿错表的后果在财务报表上很难看。支付系统里跟收入相关的表可能有好几张：按支付意图记的、按余额变动记的、按结算批次记的、扣完手续费之后的净额。每一张都真实存在，每一张都能算出数，差别在口径。agent不知道你们公司的口径，它只能挑一张看起来像的。

　　第二件事更隐蔽。同一个词的算法可能有版本差异：月度经常性收入是按签约日期归集还是按服务期间摊销，续费算不算新增，降级是记负数还是单列。这些是业务定义，不是数据库手册。让模型猜，它就会给出一个自洽但和公司口径不一致的数。

　　第三件事是动作。查账本身可逆，看错了改过来就行。但如果这个agent同时对着一批能动的工具，那么一次错误的调用带来的后果就不是一个错数，钱真的会动。可逆与不可逆的差别，是这一整套设计真正的分界线。

　　Stripe这次开放的东西，正好对着这三个失败点各给了一层。第一层是数据模型，让agent不用猜表和口径；第二层是身份，让每个接入方只拿到它该有的那部分；第三层是动作，让不可逆的操作必须经过人。前两层是工程活，第三层是流程活，而三层都留了缺口。

　　这三个失败点里，前两个不会造成事故，只会造成错误结论，而错误结论在报表上通常比权限事故更难被发现，因为它看起来完全正常。这套设计真正解决的是让模型说出可核对的数。安全是它的第三层，不是它的全部。

三层分工：表与指标、密钥与范围、确认闸门

　　三层可以用一句话分开：模型能看到什么、能进到哪里、能做什么。这三件事在实现上是独立的，混在一起谈就容易得出权限收紧了就安全这种结论。

　　第一层管能看到什么。做法是把建模过的数据连同使用说明一起给出去。Reports API里有三百张以上表的建模schema，还带一份告诉agent该怎么用这些表的指引。这样agent不必从原始表结构里推断业务含义，而是拿到一份已经写明口径的目录。

　　第二层管能进到哪里。两种认证方式：交互式客户端走OAuth，用户在授权页上可以对实盘账户和沙箱分别给不同权限；自主运行的客户端用专门发放的agent API key，只授予它真正需要的权限。密钥在后台带一个Agent标记，能被单独识别出来。

　　第三层管能做什么。资金类工具在清单里挂了人类确认标记，调用时要人点批准，批准之后执行不会自动发生，得提示agent重试。确认链接二十四小时内有效，过期就作废。

　　三层的分界在这一点上：确认闸门挡的是做完收不回来的动作，算错不归它管。所以它只出现在资金动作上，不出现在查询上。如果把确认也加到查询上，用户体验会崩，而风险并没有因此下降多少。

　　还有一个常被忽略的事实：这些写工具不是这次新加的。这次发布的是读的能力，写一直都在。把两者分开理解，才看得清这套设计的重心，它花力气解决的是怎么让agent读懂你的数据，而不是怎么让agent不闯祸，后者是既有机制在承担的。

　　三层之外还有一层容易被漏掉的东西：可核验性。每条分析都能看到底层查询语句、能确认结果怎么算出来、也能按需改查询。这不算第四层，它是第一层的出口，数据模型给了口径，可核验性保证这个口径能被追问到底。

三层怎么运作，各自留下什么缺口

　　先看数据模型这一层。三百张以上表的建模schema听起来只是个规模数字，真正的价值在建模两个字：表与表之间的关系已经被理清，指标的定义已经写进说明，agent拿到的是成品目录而不是原料堆。配套还有两百条以上的SQL模板，覆盖常见业务问题。模板的意义在于给出一条参考路径，与其让模型从零构造查询，不如让它先看这类问题通常怎么写。

　　这两组数字经常被混着引用，需要分开。三百张表是Reports API的数据模型，两百条模板是Reports v2 API附带的东西，不能推导成三百张表里有两百张有模板，也不能理解成插件关系。它们在文档里出现的段落不同，指向的层次也不同。

　　三百张表这个数字要双向看。对agent而言，候选越多，选错的概率越大：模型在几十张表里挑一张，对的可能性和在三百张里挑一张不是一回事。所以建模schema的真正贡献不是「给了多少表」，而是「给了多少判别信息」——每张表配了适用范围与指标定义的说明，模型才不至于只凭表名猜。反过来，如果只开放表结构不开放说明，三百张表就是三百个陷阱。

　　接入形态有三条。已经用上带MCP能力的客户端的，在配置里写一个服务器地址就能连；要在自己的工作流里编程接入的，直接调Queries API或Reports API。三条路的目标是同一个：让经营分析这件事从人写查询变成人说需求。

　　这也解释了发布页给出的一批示例——对账、月度经常性收入看板、欺诈率预警、支付成功率分析，都是典型的智能报表诉求。示例的作用不是展示能力上限，而是把这类需求的写法固定下来，让接入方知道该往哪个方向提问。定价上有个时间节点：Queries API对所有用户免费到2027年1月31日，之后按使用额度计费、不收月订阅；Reports API保持免费。这里要注意区分，免费期结束不等于现在就要付费，它是定价承诺的截止日。

　　可核验的出口是这个层次里最实用的一块。对财务和审计来说，它比准确率更有用：数字错了可以查，口径不清可以问，但如果只有一句模型说这个数，复核就无从下手。

　　这也是智能体接生产数据时最容易被忽略的一环。团队往往先比模型能力，最后才发现缺的是这条可追问的链路。这也解释了为什么这一层的实现要围绕表与指标而不是自由写查询，自由写查询把可解释性交给了模型，建模schema把可解释性交给了数据结构。

　　代价也很清楚。口径由厂商定义，你能用的是它建模好的那套指标；如果公司有自定义指标或者并表口径，还是得自己补一层。换句话说，这一层解决的是通用业务问题的口径，解决不了你们公司特有的算法。这一点在落地时会变成额外工作量，别指望开箱即用。

　　还有一个容易被忽略的细节：建模schema是有版本演进的。厂商新增表、调整指标定义时，接在上面的agent不会自动知道。如果没有把「这张表上次是什么时候变的」这类信息一并交出去，agent可能拿着旧口径算新数据，而结果依然自洽。这一层要长期可用，得有版本意识。

　　再看身份这一层。两个入口的选择取决于这个agent是不是有人在旁边看着。交互式客户端走OAuth：用户在Stripe的授权页上登录，可以对一个或多个实盘账户或沙箱分别授权，不同环境给不同权限。授权的会话可以在用户设置里看到，也能撤销；管理员要撤销别人的会话，需要带团队成员管理权限的角色。会话管理的作用域是当前正在看的账户或组织加上环境，撤销只在这个范围内生效，范围外的会话不受影响。

　　授权这件事还有一层容易被忽略的要求：令牌必须是为这台服务器签发的。MCP的授权规范明确要求校验受众，令牌不能转手给上游接口用。这听起来是规范细节，实际含义是「一个agent拿到的凭据，在另一个服务上不好使」，跨服务的凭据复用被堵掉了。

　　自主运行的客户端用agent API key。这类场景没有人在旁边点授权页，所以走长期凭据，但凭据要收到最小：只给这个agent真正需要的权限。密钥在后台会带Agent标记，便于把人和程序区分开；调用时把它放在请求的授权头里。文档还给了一条运维建议：换密钥时先在沙箱里验新配置，再作废旧的那把。

　　这里有个硬节点，也是整套设计里最见功力的一处。从2026年12月起，Stripe MCP不再接受未带Agent标记的全权密钥与受限密钥，这类请求会拿到401和一次OAuth发现挑战。迁移截止日是2026年11月30日。也就是说，拿一把现有密钥接上就跑这条路被主动关掉了，凭据必须按agent重新发放。用截止日把最小权限从建议变成准入条件，这一手比写十条规范有用。

　　连接账户的路更窄。如果要替平台下的连接账户取数或改数据，MCP不支持OAuth，只能用平台的agent API key，并且只授予该agent需要的连接账户权限；调用时还要传一个指定账户的请求头。这条限制在写的时候不显眼，落地时会变成一道必答题：平台型业务的agent到底代表谁。它没有第三种答案，只能二选一。

　　这一层的边界也要说清：密钥按agent发、按环境切，解决的是不同调用方不该共用一份权限。它没有解决的问题是工具粒度。这台服务器上的读工具与写工具各只有一个通用入口，读工具覆盖任意GET方法，写工具覆盖带副作用的各方法。工具粒度粗，意味着真正的最小权限落在密钥的权限配置上，而不是落在工具设计上。这是本文的判断，原文没有这样表述，它只交代了工具清单与授权方式。

　　这个权衡有代价。按作用域细分的做法是把权限做进工具，一个工具一件事，谁调用谁就被限制在那件事上；把权限做进凭据则让工具保持通用，好处是不必为每一种接口定义一个工具，几十个工具塞进上下文会挤占模型可用的空间。前者更安全，后者更省token、也更容易扩展。两条路都能走通，但责任落点不同：走后者，配置密钥的那个人就成了安全边界。这条推论同样出自本文，不是原文的结论。

　　最后看动作这一层。工具清单里有一组跟资金余额相关的工具，其中三个挂着人类确认标记：向收款方转出资金、在余额之间调拨、以及为收款方建户。前两个直接动钱，第三个是动钱的前置步骤。

　　流程是这样的：agent调用这类工具，服务器不会直接执行，而是返回一个链接；人点开链接，在后台复核请求详情，点批准；系统随即给agent一枚批准令牌，但执行不会自动继续，需要在拿到令牌后重新发起那次操作，重发时不再要求确认。二十四小时内没批准，链接过期。

　　重发这一步会牵出一个工程问题：如果重发时网络断了、或者agent不确定上一次到底成没成，它怎么办。不可逆动作的重试必须配幂等，否则一次确认可能变成两次转账。文档没有展开这层，只说了批准后有令牌、需要重发；这正好是接入方要自己补的地方，也是「批准—重试」比「批准即执行」多出来的那部分成本。

　　这个批准加重发的两段式是全文最该细看的一处。很多系统把确认做成一次同步等待：批准之后原请求继续往下走。这里没有这么做，它把确认做成一张可在事后短期兑换的凭证。好处是确认与执行解耦，人可以在方便的时候批；代价是agent必须有能力处理被挂起再重试这个状态，否则一次批准就白费了。

　　还有一处容易误读：这套确认与MCP客户端自己的工具批准开关是两套东西。文档写得很明确，厂商的确认要求独立于客户端的工具批准设置，账户级还能配置额外规则要求复核更多动作。也就是说，客户端里把每个工具调用都要我点同意打开，不等于满足了厂商侧的确认要求。

　　那么这道闸门管什么。它管的是这个动作有没有被一个有权限的人看见并同意。它不管金额对不对、收款方对不对、这笔业务该不该做，这些判断仍然在业务侧。把确认当成安全兜底，是这一层最容易被过度信任的地方。

　　工具名也能说明另一件事：一个写工具可以承载多种动作，是否需要确认取决于具体动作，而不只取决于工具名。所以「我把危险工具禁掉了」这句话在这种设计下并不总成立，得看动作级别。文档里没有任何一份哪些动作需要确认的完整清单，只有工具参考页上的标记，这本身就是一个需要留意的信息缺口。

四个看起来合理、其实不成立的假设

　　第一个假设：读工具既然只能读，风险就低。读工具确实覆盖任意GET方法，但读的边界取决于密钥权限，不取决于工具。这一层判断本文自己担，原文只说了工具覆盖范围。一把权限过宽的密钥配上只读工具，照样能读走不该读的东西。读的风险在数据面，不在动作面。

　　第二个假设：客户端开了工具批准，就等于有人把关。两套机制并存这件事前面已经交代，结论是：客户端批准是用户体验层的开关，厂商的确认是动作层的规则，账户级还能再加。任何一层被当成全部，都会漏。

　　第三个假设：接上就能用。三百张表意味着选择空间很大，选错表的风险还在。建模schema降低了猜错的概率，但没有消除它；两百条模板给的是参考路径，不是保证。要拿到能对外汇报的数字，仍然需要有人确认口径。

　　第四个假设：有确认就安全。这一条最难接受，也最需要说清。确认绑定的是这一次请求，而攻击面往往在请求生成的环节：如果agent读到的某段内容里藏了指令，它可能构造出一个看起来正常的调用，人点批准的时候看到的是一个合理的金额和一个陌生的收款方。

　　OWASP关于MCP安全的清单里把这类风险列得很清楚，还包括另一个更隐蔽的形态，服务器在首次批准之后改掉工具定义，让一个已经被信任的工具变成另一个东西。这些都不是多加一次点击能解决的，需要把审批绑定到动作与参数本身。文档公开了确认流程，但没有说明参数级绑定的程度，这是该追问的地方。

　　这四个假设还有个共同的时间特征：它们在项目早期最容易成立，在后期最容易失效。刚接上的时候，表少、指标窄、调用频率低，每一层看起来都够用；跑三个月之后，表加了几十张、指标改过两版、agent开始被授予更多权限，原本够用的边界就松了。所以每一层都需要一个复查节奏，而不是一次配置。

　　四个假设有个共同点：它们都是把某一层的存在误当成某一层的有效。有读工具就以为读安全，有客户端批准就以为有人把关，有schema就以为不会选错，有确认就以为安全。每一层解决的是它自己那个问题，跨层兜底从来不会自动发生。

给国内金融系统落地这件事的五条判断

　　第一条，数据模型这一层最值得先做，而且和厂商无关。把指标定义写成机器能读的目录，配上这类问题该用哪张表的说明，再留一个能看底层查询的出口，这三件事在任何自建系统里都能落地，收益也最直接：它把模型答得对不对变成口径有没有写清，后者是可以审计的。

　　第二条，凭据按调用方发、按环境切，比共用一把全权密钥省心。用强制迁移把这条变成硬约束，是个值得抄的做法：设定一个截止日，之后不接受旧形态的凭据，让最小权限从建议变成准入条件。国内做内部agent平台时，同样的手法可以用在服务账号上，先给出迁移窗口，再在某个日期之后拒绝旧凭据。

　　第三条，不可逆动作的闸门要设计成两段，而不是一段。批准即执行在工程上简单，但它把确认和执行绑死在一次调用里，人不在就没法批；两段式把两者拆开，代价是agent要能处理挂起与重试的状态。这个代价该付，因为金融场景里真正不可逆的动作不多，而每一次都值得慢一点。

　　第四条在流程侧：把追问清单写进验收。接完这套东西之后，至少能被回答的问题有四个——这次分析用了哪张表、底层语句长什么样、读这份数据用的是哪种凭据、这个动作有没有经过人工确认。四个问题里只要有一个答不上来，就不该让它进入对外汇报的链路。

　　第五条不那么技术，却更容易被忽略。这套东西的价值有相当一部分来自可核验而不是自动化。如果上线的结果是一份没人能复核的分析，那它带来的风险大于收益；反过来，如果每条结论都能回看到一句查询，那么即使答案错了，纠错成本也低。选型时把可核验性作为硬指标，比比较谁的模型更强更能决定这件事做成什么样。

　　一条反向提醒：agent直连不是唯一选项。Stripe自己还留着另一条路，即Stripe Data Pipeline，把数据同步进数据仓库或数据湖再查。这条路的老问题是要维护同步管道和一份副本，新问题是副本会让最新与可查之间出现时差。选哪条取决于你要的是即时性还是可治理性，两者并不总是同一件事。

来源：Stripe Blog《Analyze your Stripe data directly with your agent》— 300+张建模表、3条接入路径；Stripe Docs《Model Context Protocol (MCP)》— 2种认证方式、3个确认工具、24小时确认有效期；Stripe Docs《How the Reports API works》— 200+条SQL模板、6类报表