跳转至

你的 MCP 服务器足够安全，但其背后的账本系统并非如此

Your MCP Server Is Secure. The Ledger Behind It Isn’t.

Article Featured Image

文章背景与核心概要

随着模型上下文协议 (Model Context Protocol, MCP) 成为连接 AI 智能体 (AI Agent) 与企业数据的全新事实标准，开发者们大多将安全防线筑牢在 MCP 服务器本身的鉴权与细粒度角色控制上。然而，拥有连接 32 款企业级财会与 ERP 系统实战经验的资深架构师指出，一个被普遍忽视的致命盲区在于——服务器后方赖以支撑的“底层账本与业务系统”，在安全能力上往往还停留在十多年前的刀耕火种时代。现实中大量上游系统缺乏 OAuth 支持、采用永久有效且无法远程吊销的静态秘钥，更无法在审计日志中区分凌晨 3 点疯狂记账 400 笔的是勤奋的财务主管还是失控的 AI 智能体。本文深度剖析了这一“前锋固若金汤、后方门户大开”的严峻安全断层，指出了集成层能力的边界，并针对当下与未来的企业级智能体架构给出了兼顾务实与前瞻的破局解法。

执行摘要

Executive Summary

尽管构建安全的模型上下文协议 (Model Context Protocol, MCP) 服务器的最佳实践，将大量精力倾注在集成层的细粒度角色划分与身份认证上，但它们往往忽略了一个致命的盲区：位于服务器背后的底层业务系统，往往根本无法达到同等水准的安全标准。

While best practices for building secure Model Context Protocol (MCP) servers focus heavily on fine-grained roles and authentication at the integration layer, they often overlook a critical blind spot: the systems behind the server cannot always be secured to the same standard.

基于将系统接入 32 款主流财会与企业资源规划 (ERP) 系统的真实工程洞见，本文深入探讨了上游企业级软件所暴露的安全短板、中间集成层能够（以及无法）施加的安全约束，并提出了切实可行的应对策略——例如设立专属智能体用户与引入身份委托标准，以全力护航与敏感财务账本交互的 AI 智能体 (AI Agent) 。

Based on insights from connecting to 32 accounting and ERP systems, this article explores the security gaps in upstream enterprise software, what integration layers can (and cannot) enforce, and practical strategies—such as dedicated agent users and delegated identity standards—to secure AI agents interacting with sensitive financial ledgers.

在 Unite.AI 近期刊登的一篇文章中，Gil Feig 总结了构建安全 MCP 服务器的六大最佳实践。这些建议非常中肯，任何正在交付 MCP 服务器的团队都应当遵循。他在文中建议为每一个集成赋予“独立的细粒度角色，权限范围严格限定于所需权限”，这一观点切中要害。但这种设计暗含了一个前提：通信另一端的底层系统同样具备细粒度的角色控制能力。这恰恰揭示了一个在业界鲜有人提及的普遍假设——人们总是一厢情愿地认为，服务器后方的底层系统也能被加固到同样严苛的安全标准。

In a recent piece here on Unite.AI, Gil Feig laid out six best practices for building a secure MCP server. They are sound, and anyone shipping an MCP server should follow them. His advice to give each integration “its own fine-grained role, scoped strictly to required permissions” is exactly right. It also assumes the system on the other end has fine-grained roles. That points to a broader assumption that rarely gets stated: that the systems behind the server can be secured to the same standard.

但在现实的商业软件世界中，情况往往并非如此。我带领的工程团队负责维护一套连接 32 款财会与 ERP 系统的集成层架构，并在其顶层挂载了一个可选的 MCP 服务器。在日常运维中，我们屡见不鲜的场景是：在我们这一侧，智能体的身份认证严密合规、权限范围限定清晰、行为调用审计完整；但当它向底层系统写入数据时，对方系统却全然不知其实际是由一个智能体发起的。

In business software, they often cannot. I run the engineering team behind an integration layer that connects to 32 accounting and ERP systems, with an optional MCP server on top. We regularly see agents that are well authenticated, well scoped and well logged on our side, writing into systems that have no way of knowing an agent was involved at all.

本文聚焦探讨的正是硬币的另一面：上游底层系统究竟具备怎样的真实能力、我们在中间集成层究竟能够把控什么，以及这种技术控制力的边界究竟止步于何处。

This piece is about that second half of the problem: what the upstream systems actually offer, what you can control from the integration layer, and where that control ends.

MCP 规范的责任边界止于何处

Where the MCP Spec Hands Over

MCP 授权规范对其自身的权责边界给出了极其清晰的界定。对于下游客户端而言，MCP 服务器扮演着 OAuth 资源服务器的角色；而当它调用上游系统的 API 时，它则摇身一变成为一个独立的 OAuth 客户端，使用上游系统所签发的独立 Token 进行认证。规范明确禁止将客户端的凭证 Token 直接透传给上游。

The MCP authorization specification is clear about its own boundary. The MCP server is an OAuth resource server for its clients. When it calls an upstream API, it acts as a separate OAuth client, with a separate token issued by the upstream system. Passing the client’s token through is explicitly forbidden.

这是一个无懈可击的技术设计。但它同时也意味着：有关上游 API 调用的方方面面——包括究竟允许谁来执行何种操作、这些操作又是如何被系统日志记录下来的——全都完全仰仗上游系统自身的能耐。如果上游系统本身功能缺失，MCP 规范也无法凭空将其补齐。

That is the right design. It also means everything about the upstream call, including who is allowed to do what and how that is recorded, depends entirely on the upstream system. The spec cannot fix what the upstream system does not offer.

OWASP 针对过度自主代理 (Excessive Agency) 的安全防范指南同样面临这一窘境。该指南建议将智能体扩展插件在其他外部系统中所持有的权限严控在最小必要范围之内，并且所有操作必须在它所代表的真实用户的上下文环境中执行。这两条都是极具指导意义的良言；但它们也无一例外地默认：目标系统有能力精准表达最小权限与用户上下文。

The same goes for the OWASP guidance on excessive agency. It recommends limiting the permissions an agent’s extensions hold in other systems to the minimum necessary and executing actions in the context of the user they act for. Both are good advice. Both assume the other system has a way to express minimum permissions and user context.

上游系统现状的真实图景

What the Upstream Systems Actually Offer

站在系统集成商的视角，我们所接入的 32 款财会与 ERP 系统的真实面貌如下。

Here is what the 32 accounting and ERP systems we connect to look like from an integrator’s seat.

三分之一的系统根本不支持 OAuth

A third have no OAuth at all

在这 32 款系统中，有 21 款支持 OAuth；另外 11 款则完全依赖静态凭证：例如 API Key、用户名密码组合、或双 Token 认证机制。其中一部分密钥甚至永久有效。某款被广泛应用的主流系统在官方文档中直言不讳地写道：只要该用户账号存在一天，其 API Token 的有效期就是无限期。

21 of the 32 use OAuth. The other 11 rely on static credentials: API keys, username and password, or a pair of tokens. Some of those keys never expire. One widely used system documents its API tokens as having an unlimited lifetime for as long as the user exists.

凭证超长待机，吊销机制几乎缺位

Long life, little revocation

即便支持了 OAuth，它带来的安全收益也远比你预期的要低。有一家服务商签发的刷新令牌 (Refresh Token)，其有效期限居然长达约 20 年。这枚凭据的使用寿命不仅注定超越正在使用它的 AI 智能体自身，超越构建该智能体的底层技术框架，甚至极大概率比当年点击“授权允许”按钮的员工在职时间还要长。而在另一套系统中，就连访问令牌 (Access Token) 都是永不过期的。

OAuth helps less than you would hope. One provider issues refresh tokens with a lifetime of roughly 20 years. That is a credential designed to outlive the agent using it, the framework the agent was built on, and quite possibly the person who clicked “allow”. In another system, even the access tokens do not expire.

更严重的是，一旦凭据被签发并分发出去，谁又有权将其关闭吊销？针对这一需求的行业标准——OAuth Token 吊销协议 (RFC 7009) 早在 2013 年便已确立。然而在现实中，大约 40% 的系统根本没有向集成商提供任何吊销凭证的技术接口。所有采用 API Key 的系统统统落入此列。唯一的补救手段，只能是通过工单或邮件乞求客户管理员登录后台界面，手动点击删除对应访问权限。

And once a credential is out, the question is who can switch it off. The standard for that, OAuth token revocation (RFC 7009), has existed since 2013. Yet roughly four in ten of the systems give an integrator no technical way to revoke credentials. Every API-key system falls into that group. The only remaining control is asking the customer to delete the access by hand.

权限颗粒度粗糙，智能体身份不可见

Coarse scopes, no agent identity

绝大多数静态密钥只会全盘继承创建该密钥的用户账号的全部特权；只有极少数系统允许你将密钥限定在特定的单个 API 端点上。许多 OAuth 系统虽然声称支持权限范围 (Scopes)，但颗粒度往往极其粗糙，大体停留在“财务模块，读写全部放开”这种粗放水准。更致命的是，在这 32 款系统中，我们找不出任何一款能够通过 API 接口，在同一笔交易记录中同时登记“智能体本身”与“它所代表的真实操作人”的双重身份。对于外部智能体，系统日志里记录的要么是当初绑定授权的那个自然人用户，要么就是一个模糊通用的系统服务账号。极为耐人寻味的是，某些软件厂商在自己的核心产品中原生内置智能体时——例如 Microsoft 在 Business Central 中的做法——却悄悄为智能体分配了专属的用户账号。这与我后文推荐的架构模式完全一致，只不过厂商们通常只把这种特权留给了自家的亲儿子智能体。

Most static keys simply inherit the full rights of the user who created them; only a few systems let you restrict a key to individual endpoints. Many OAuth systems have scopes, but they tend to be coarse, along the lines of “accounting, read and write”. And in none of the 32 systems could we find a way to record, through the API, both the agent and the person it acts for on the same transaction. External agents show up either as the user who connected them or as a generic system user. Tellingly, where a vendor has built agents into its own product, as Microsoft has in Business Central, it gave them dedicated user accounts. That is the same pattern I recommend below, just reserved for the vendor’s own agents.

集成层能够强行落实的控制措施

What the Integration Layer Can Enforce

面临上述严峻现状，并不意味着我们只能束手就擒。横亘在 AI 智能体与财务系统之间，你在集成层几乎可以掌控全局：

None of this means giving up. Between the agent and the accounting system, you control almost everything:

  • 为访问集成层的每一个智能体签发独立的鉴权凭证；
  • 定义你自己的细粒度权限范围，例如对发票模块仅开放只读访问；
  • 详尽记录每一次智能体调用的审计日志，并明确关联其所代理的具体自然人；
  • 强制使用幂等键 (Idempotency Keys)，防止智能体在发生网络重试时对同一张发票重复记账入账；
  • 针对单个智能体实施调用频率限制 (Rate Limits)；
  • 在执行任何写入或修改操作前，插入人工或规则审批流程。
  • per-agent credentials towards your own layer
  • your own scopes, for example read-only access to invoices
  • an audit log of every agent call, with the human it acted for
  • idempotency keys, so a retrying agent does not book the same invoice twice
  • rate limits per agent
  • approval steps before any write

上述每一项控制措施，都完全不依赖于目标底层系统支持与否。在集成层构建一个功能完备的访问控制层，在技术上早已完全可行；只要你的智能体工作流触及哪怕一丁点财务数据，你就必须毫不犹豫地搭建这一防线。

None of that depends on what the target system supports. A capable access layer at the integration tier is possible today, and if you put agents anywhere near financial data, you should build one.

防线止步之处：系统边界的断裂

Where It Stops

但你唯一无法做到的，是将这套严密的防护体系穿透延伸到底层系统的边界之外。一旦越过这道分水岭，三项核心安全基石便会土崩瓦解。

What you cannot do is extend that layer past the system boundary. Three things break there.

行为归因断层 (Attribution)

Attribution

在财务系统内部，智能体写入的账目流水在登记人一栏显示的，要么是当初授权系统绑定的某位员工，要么就是一个通用的技术服务用户。任何对该系统进行合规审计的人员，看到的都只是一笔由该用户完成的过账操作。他们完全无法判断这笔账究竟是人类操作还是智能体行为。在财务账本看来，一个在凌晨 3 点疯狂过账 400 笔发票的智能体，和一个格外通宵达旦、忘我工作的财务经理毫无二致。要想还原真相，就必须调取集成商中间层的日志记录，而这与企业法定的核心记账系统 (System of Record) 属于完全不同的信任链条。对于事后数字取证或严肃的合规审计而言，这无疑处于极其被动脆弱的劣势。

Inside the accounting system, the agent’s write appears as whoever authorised the connection, or as a technical user. Anyone auditing that system sees a posting by that user. They cannot tell whether a person or an agent made it. To the ledger, an agent that books 400 invoices at 3 a.m. looks exactly like a very diligent finance manager. Reconstructing that requires the integrator’s logs, which is a different chain of trust from the system of record. For forensics or an audit, that is a weak position.

绝大多数企业在这一挑战面前同样准备不足。在云安全联盟 (Cloud Security Alliance) 开展的一项权威调研中，仅有 28% 的受访企业表示其能够在跨异构环境下可靠地将智能体的行为归因溯源至具体的自然人或系统；更有高达 44% 的企业正在使用或计划对其智能体使用静态 API Key。

Most organisations are not ahead of this either. In a Cloud Security Alliance survey, only 28% of respondents said they could reliably trace agent actions to a human or system across all environments, and 44% use or plan to use static API keys for their agents.

最小权限原则名存实亡 (Least Privilege)

Least privilege

你在集成层固然可以严加约束，强制要求某个智能体只能读取发票数据。但如果目标底层系统本身不支持权限范围划分，那么你的集成层在调用底层系统时所使用的后台凭证依然享有至高无上的全部权限。任何一旦窃取或泄漏该凭据的攻击者，都可以彻底绕过你精心构筑的集成防护层，让你辛辛苦苦编写的每一条安全规则瞬间失效。

You can enforce that an agent only reads invoices. But if the target system has no scopes, the credentials behind your layer still carry full access. Anyone who obtains them bypasses your layer entirely, and every rule you wrote with it.

凭证吊销无门 (Revocation)

Revocation

在你自己搭建的中间层上，你确实能够在一瞬间切断对违规智能体的访问权限。但如果连通目标底层系统的真正凭据本身发生了泄漏，中间层的拦截就毫无意义。而面对那四成根本不提供吊销接口的系统，你唯一的“紧急熔断开关”，就只有给客户管理员发一封人工邮件。

You can cut off your own agent instantly. That does not help if the credentials to the target system itself are compromised. And for the four in ten systems without a revocation endpoint, the kill switch is an email to the customer.

务实的破局之道：设立专属智能体账号

The Pragmatic Answer: A Dedicated Agent User

在当下，你能够采取的最行之有效的解决方案其实一点也不光鲜亮丽：直接在目标底层系统中为智能体创建一个专属的独立用户账号，并强制要求智能体仅能通过该账号登录和连接。

The most useful thing you can do today is unglamorous. Create a dedicated user for the agent in the target system and connect the agent through that user only.

只要目标系统支持创建用户，这种方法就百试百灵，并且它能为你争取到集成层无论如何也提供不了的三大核心安全红利：

It works on every system that lets you create users, and it buys three things the integration layer cannot:

  • 核心记录系统内部的原生归因：账目流水在系统中的过账人会直接显示为“应付账款智能体 (AP agent) ”，而不再是半年前随手点击“连接”授权的财务经理。
  • 即便缺少 API 也依然保有的吊销通道：客户管理员随时可以在系统管理界面中直接禁用该用户账号，这在那些缺乏凭证吊销接口的系统中构成了坚不可摧的终极刹车阀。
  • 局部落实最小权限原则：只要目标系统具备哪怕最简陋的角色模型，通常就能将这个智能体用户仅绑定到它实际开展业务所需的少数几个模块上。
  • Attribution in the system of record. Postings show up as “AP agent”, not as the finance manager who clicked “connect” six months ago.
  • A revocation path, even without an API for it. The customer can disable the user in the interface, which works on systems that offer no revocation endpoint.
  • Partial least privilege. Where the system has any role model at all, the agent user can often be restricted to the modules it actually needs.

当然，这一方案并非毫无代价。在客户入驻激活的关键节点上，必须有人手动在系统后台创建这个账号，这恰恰在最影响用户体验的环节增加了操作摩擦力。此外，大约有一半的系统是按照用户席位数收费的——在小型企业工具中每个席位每月可能只需几欧元，而在完备的企业级 ERP 中则动辄超过一百欧元。还有一些系统根据订阅套餐对用户上限设卡，多开一个账号可能迫使整家企业被迫升级到高出数级的昂贵套餐。再者，一个无人认领、权责不清的服务账号本身也会孕育新的安全隐患，沦为 Unite.AI 此前曾深度报道过的非人类身份 (NHI) 野蛮蔓延危机的一环。就像任何正常的人类员工账号一样，它必须明确指定责任人并设置定期的权限审查周期。

The costs are real. Someone has to create the user by hand during onboarding, which adds friction at exactly the wrong moment. About half of the systems charge for every additional user, from a few euros a month in small-business tools to more than a hundred in a full ERP. Several others cap users by plan, so one more user can mean a more expensive plan for the whole company. And a service user that nobody owns becomes its own risk, part of the non-human identity sprawl Unite.AI has covered before. It needs an owner and a review date like any other account.

不仅如此，这种土办法也无法解决那些本身就缺乏权限划分机制的系统的先天缺陷。但它至少成功将“行为归因”与“凭据吊销”这两项至关重要的安全支柱，稳稳拉回到了审计人员真正盯视的核心业务系统内部。

It also does not fix scopes in systems that have none. But it moves attribution and revocation back into the system where auditors actually look.

结构性的根本解法：委托身份体系

The Structural Answer: Delegated Identity

真正标准完备的教科书式答案，其实在行业技术规范中早已赫然在列。OAuth 2.0 Token 交换规范 (RFC 8693) 严谨地区分了“冒充 (Impersonation) ”与“委托 (Delegation) ”这两种迥异的授权模式。在委托模式下，智能体得以保留属于自己的独立机器身份，同时其所持有的 Token 会通过标准的 act 声明，明确铭刻下“该智能体正在代表某位自然人代行职责”这一事实。

The correct answer already exists on paper. OAuth 2.0 Token Exchange (RFC 8693) distinguishes impersonation from delegation. With delegation, the agent keeps its own identity and the token records that it acts on behalf of a person, through the “act” claim.

如果将这一优雅的设计映射到财会记账体系中，它将意味着：

Applied to accounting, that would mean:

  • 财务账本能够白纸黑字地记录下“某特定智能体代表某特定自然人执行了此笔记账”；
  • 权限范围是基于每次独立的委托关系精准授予的，而非草率地按整个用户账号打包授权；
  • 可以精准地单独撤销某一项授权委托，而完全不必触动该自然人原本的主账户权限。
  • the ledger records that this agent posted on behalf of this person
  • scopes are granted per delegation, not per user
  • a single delegation can be revoked without touching the person’s account

然而，就目前我们在行业中的摸查而言，在这 32 款主流系统中，没有哪怕一家支持类似的机制。因此在当下，它依然只是一个理想的演进方向，而非立即可用的工程选项。这与其说是留给系统集成商的技术作业，倒不如说是直接向财会与 ERP 软件厂商发出的时代呼吁：AI 智能体早已在不可逆转地向你们的核心账本写入海量数据，你们的 API 接口是时候光明正大地记录下这一事实了。

As far as I could find, none of the 32 systems supports anything like it. So for now it stays a direction, not an option. That makes it a request to the providers of accounting and ERP software rather than a task for integrators: agents are already writing to your ledgers, and your APIs should be able to say so.

在智能体触碰账本之前必须完成的检查清单

What to Do Before an Agent Touches a Ledger

如果你正准备将 AI 智能体接入财会或 ERP 系统，这里有一份简明扼要的避坑清单供你逐项对照核查：

If you are connecting agents to accounting or ERP systems, a short checklist:

  1. 全面摸底每个目标系统的凭证机制：摸清对方是采用 OAuth 还是静态密钥？凭证有效期限是多久？是否支持权限范围划分？发生泄漏时是否具备吊销接口？
  2. 无论底层系统多么简陋，中间访问控制层必须搭建：无论目标系统能力如何，单智能体身份鉴权、细粒度权限管控、幂等性保障以及关键操作人工审批，必须统统收敛在你的集成层强行兜底。
  3. 只要系统条件允许，坚决启用专属智能体账号：将客户初始配置时的操作摩擦与额外的软件许可席位费用，坦然视作为获取核心系统行为归因能力所必须支付的合理代价。
  4. 确保你这一侧的审计追踪具备防篡改能力：对于市面上绝大部分底层系统而言，中间层的日志将成为证实“智能体曾介入此项业务”的唯一孤证。
  5. 在风险登记册中坦率记录残留风险：若某些系统确实既无权限管控也无吊销机制，请务必开诚布公地将这一隐患如实告知客户，并在企业自身的安全风险登记册中如实立卷留存。
  1. Map each target system’s credential model. Is it OAuth or a static key, how long does the credential live, does it have scopes, and can you revoke it?
  2. Build your access layer anyway. Per-agent identity, scopes, idempotency and approvals belong on your side, whatever the target offers.
  3. Use a dedicated agent user wherever the system allows it. Accept the onboarding effort and license cost as the price of attribution.
  4. Keep your own audit trail tamper-evident. For many systems it will be the only record that an agent was involved.
  5. Write down the residual risk. Where a system has no scopes and no revocation, say so, to your customer and to your own risk register.

系统边界才是真正的胜负手

The Boundary Is the Point

全力保障你的 MCP 服务器本身的安全固然不可或缺，但这绝非万事大吉。当一个智能体被赋予向核心账本写入数据的能力时，它的真正安全水位，完全取决于你的集成层与核心记录系统之间的那道交界边界——而在今天，这道边界的严密程度完全由那些古老的底层系统所决定，根本由不得你做主。

Securing your MCP server is necessary. It is not sufficient. The security of an agent that writes to a ledger is decided at the boundary between your layer and the system of record, and today that boundary is set by the systems, not by you.

但值得庆幸的是，这一安全断层的轮廓已经被清晰界定，成熟的行业技术规范也早已就绪。当下唯一欠缺的，就是那些真正掌管着企业核心账本的底层软件厂商们，能够真正迈出支持这些标准的那一步。

The good news is that the gap is well defined. The standards exist. What is missing is support for them in the systems that hold the books.

关于作者

About the Author

Lennart Svensson，maesn 首席技术官 (CTO)
Lennart Svensson 现任 maesn 的 CTO，主导开发用于将软件连接至 30 多款财会与 ERP 系统的集成层平台。他此前曾在多家欧洲大型企业担任系统架构师与软件工程师。

Lennart Svensson, CTO, maesn
Lennart Svensson is CTO of maesn, where he builds the integration layer connecting software to more than 30 accounting and ERP systems. He previously worked as architect and software engineer in large enterprises in Europe.

拓展阅读

Discover More