[{"data":1,"prerenderedAt":614},["ShallowReactive",2],{"blog-\u002Fblog\u002Fmcp-server-sap-authorization":3,"blog-related-\u002Fblog\u002Fmcp-server-sap-authorization":595},{"id":4,"title":5,"audience":6,"body":11,"cluster":525,"conversionGoal":526,"cornerstone":527,"date":528,"description":529,"draft":527,"extension":530,"factCheckedAt":528,"faq":531,"featured":527,"language":526,"meta":544,"minRead":545,"navigation":546,"order":547,"originalAsset":526,"path":548,"pillar":549,"primaryKeyword":550,"publicationOrder":551,"relatedProject":526,"releaseScope":552,"reviewCycle":553,"reviewMethod":554,"reviewStatus":555,"reviewedAt":528,"reviewedBy":556,"searchIntent":557,"seo":558,"sources":559,"stem":587,"tags":588,"type":593,"updated":528,"__hash__":594},"blog\u002Fblog\u002Fmcp-server-sap-authorization.md","MCP Server in Front of SAP: Where Authorization Lives",[7,8,9,10],"enterprise-architect","solution-architect","treasury-system-lead","financial-controller",{"type":12,"value":13,"toc":513},"minimark",[14,22,31,36,51,54,87,90,93,97,153,156,160,168,174,185,192,198,202,205,243,246,249,270,274,277,300,317,321,324,377,388,391,395,449,456,471,475,495,498],[15,16,17,21],"p",{},[18,19,20],"strong",{},"An MCP server in front of SAP adds a hop, not a control. The Model Context Protocol governs how an agent's client authenticates to the MCP server, and it forbids passing that token on. The MCP server then calls SAP with a separate credential, and whichever user that credential logs on as is the user SAP checks, logs and writes on the document."," Authorization, segregation of duties and the record of what happened all live on the SAP side of the MCP server, in the identity used for that second hop and in the checks the called code performs. If they aren't designed there, they don't exist anywhere.",[15,23,24,25,30],{},"The case for ",[26,27,29],"a",{"href":28},"\u002Fblog\u002Fconnecting-ai-agents-to-your-erp","putting a service layer between an agent and the ERP"," is made elsewhere on this site. MCP is now the most common way that layer gets built, so this page reads the protocol as it currently stands, revision 2026-07-28, against the SAP side, and marks where each responsibility actually sits.",[32,33,35],"h2",{"id":34},"what-mcp-standardizes","What MCP standardizes",[15,37,38,39,42,43,46,47,50],{},"MCP is an open protocol, built on JSON-RPC, for connecting LLM applications to tools and data. A ",[18,40,41],{},"host"," application runs ",[18,44,45],{},"clients"," that connect to ",[18,48,49],{},"servers",", and servers expose tools with schema-described inputs and outputs. The 2026-07-28 revision made the protocol stateless, and it defines two transports that matter here: STDIO for a local process, and Streamable HTTP for a remote server.",[15,52,53],{},"Its authorization rules are narrower than people assume:",[55,56,57,73,80],"ul",{},[58,59,60,61,64,65,68,69,72],"li",{},"Authorization is ",[18,62,63],{},"optional",". When supported, HTTP-based implementations ",[18,66,67],{},"should"," follow the specification's OAuth 2.1 model. STDIO implementations ",[18,70,71],{},"should not",", and instead retrieve credentials from the environment.",[58,74,75,76,79],{},"A protected MCP server acts as an ",[18,77,78],{},"OAuth 2.1 resource server",". It must validate that access tokens were issued specifically for it as the intended audience, and reject the rest.",[58,81,82,83,86],{},"MCP servers ",[18,84,85],{},"must not accept or transit any other tokens",". The security considerations spell out the consequence: if the server calls upstream APIs, the token it uses there is a separate token, issued by the upstream authorization server, and the MCP server must not pass through the token it received from the client.",[15,88,89],{},"The last rule is the one that matters for SAP. The protocol deliberately stops at its own boundary: MCP gives you a well-authenticated call into the MCP server and says nothing about the call out of it.",[15,91,92],{},"The STDIO rule deserves a second look in a finance context. \"Credentials from the environment\" on a developer laptop running a local MCP server against SAP usually means a stored SAP user and password. That is usually a technical user, and nobody reviews it.",[32,94,96],{"id":95},"three-hops-three-owners","Three hops, three owners",[98,99,100,116],"table",{},[101,102,103],"thead",{},[104,105,106,110,113],"tr",{},[107,108,109],"th",{},"Hop",[107,111,112],{},"What decides who is allowed",[107,114,115],{},"Who owns it",[117,118,119,131,142],"tbody",{},[104,120,121,125,128],{},[122,123,124],"td",{},"1. Agent client → MCP server",[122,126,127],{},"MCP authorization: OAuth 2.1, audience-bound tokens, scopes",[122,129,130],{},"Whoever runs the MCP server and its IdP",[104,132,133,136,139],{},[122,134,135],{},"2. MCP server → SAP",[122,137,138],{},"The credential the server uses: technical user, propagated user, agent user",[122,140,141],{},"You, and nothing in MCP decides it",[104,143,144,147,150],{},[122,145,146],{},"3. Inside SAP",[122,148,149],{},"Authorization checks against authorization objects for the logged-on user",[122,151,152],{},"SAP roles, and the code being called",[15,154,155],{},"Most designs spend their effort on hop 1, because that's where the protocol has something to say. Hop 1 decides who may talk to the MCP server. What they can do in SAP is decided at hops 2 and 3.",[32,157,159],{"id":158},"hop-2-technical-user-or-principal-propagation","Hop 2: technical user or principal propagation",[15,161,162,163,167],{},"This is the same decision ",[26,164,166],{"href":165},"\u002Fblog\u002Fagent-identity-and-permissions","agent identity"," lays out in general. The MCP server is simply the place it gets made.",[15,169,170,173],{},[18,171,172],{},"A technical user"," is the default because it's one credential in one configuration file. SAP sees one identity for every requester. Documents name the integration. Every authorization check runs against the union of rights that user accumulated, and revoking it stops every agent at once. A well-built OAuth flow at hop 1 doesn't change any of that: the requester's identity is authenticated all the way to the MCP server, then discarded at the one place SAP could have used it.",[15,175,176,179,180,184],{},[18,177,178],{},"Principal propagation"," carries the requesting person's identity into SAP, so SAP's existing roles apply to the call. It's the model SAP itself describes for ",[26,181,183],{"href":182},"\u002Fblog\u002Fsap-cash-application-ai","Joule and its other finance AI",": the assistant acts on behalf of the logged-on user through principal propagation, with the Cloud Connector creating a backend-consumable identity from the trusted user context, and actions subject to that user's roles. For an MCP server, the equivalent is to exchange the requester's identity for an SAP-side credential at hop 2, which the specification's \"separate token issued by the upstream authorization server\" explicitly allows, rather than logging on as itself.",[15,186,187,188,191],{},"Its costs are real and should be stated. The agent inherits everything that person can do, not just what the task needs, and the document names a person who didn't click. The strongest arrangement combines the two: an ",[18,189,190],{},"agent-specific SAP user whose effective rights are bounded by the requester",", with the requester recorded. It costs more to build, and it's the only arrangement where an SAP document answers both questions an investigation asks: what acted, and for whom.",[193,194,195],"pull-quote",{},[15,196,197],{},"The MCP spec authenticates the requester all the way to the MCP server. A technical user then throws that identity away at the one place SAP could have used it.",[32,199,201],{"id":200},"hop-3-where-authorization-really-runs","Hop 3: where authorization really runs",[15,203,204],{},"Inside SAP, authorization is performed by the code being called, against the user it runs as. SAP's own ABAP guidance is blunt about the parts people forget:",[55,206,207,219,225,232],{},[58,208,209,210,214,215,218],{},"An ",[211,212,213],"code",{},"AUTHORITY-CHECK"," statement checks whether an authorization is available ",[18,216,217],{},"for the current user",", determined by values in an authorization object.",[58,220,221,224],{},[18,222,223],{},"ABAP SQL statements trigger no authorization checks"," in the database. Tables can be read without restriction, and SAP states that it's up to the programmer to ensure the user is authorized for the data the program handles.",[58,226,227,228,231],{},"Reads through CDS can be protected implicitly by ",[18,229,230],{},"CDS access control",", if the view has an access control defined and enforced.",[58,233,234,235,238,239,242],{},"A ",[211,236,237],{},"sy-subrc"," of 0 means the check succeeded ",[18,240,241],{},"or no check was performed",".",[15,244,245],{},"Put an MCP server in front of that and the risk becomes concrete. Released BAPIs and OData services carry the application's own authorization checks. A custom function module or service written quickly \"for the MCP server\", one that selects from tables and returns the rows, carries only the checks its author remembered to write. The MCP server will expose it with a clean JSON schema, and nothing about the schema tells you whether it checks anything.",[15,247,248],{},"So the rules for hop 3 are simple:",[250,251,252,258,264],"ol",{},[58,253,254,257],{},[18,255,256],{},"Expose released APIs, not custom table reads."," Where a custom wrapper is unavoidable, review its authorization checks like any other code going to production.",[58,259,260,263],{},[18,261,262],{},"Test with the SAP identity from hop 2, not with a developer user."," A tool that works in testing with broad developer authorizations and fails in production is behaving correctly.",[58,265,266,269],{},[18,267,268],{},"Treat tool annotations as descriptions, not controls."," The specification itself says clients must consider tool annotations untrusted unless they come from trusted servers. A tool described as harmless is harmless only if the SAP user behind it can't do harm.",[32,271,273],{"id":272},"segregation-of-duties-lives-in-two-places","Segregation of duties lives in two places",[15,275,276],{},"With MCP, segregation of duties has to hold in two lists:",[55,278,279,289],{},[58,280,281,284,285,288],{},[18,282,283],{},"The tool list."," An MCP server exposing a generic \"call any BAPI\" or \"run any OData query\" tool is the direct connection with a new label. The operation list should be written by you, one verb and one scope per tool, as argued in ",[26,286,287],{"href":28},"connecting agents to the ERP",". An MCP server that creates vendors and one that proposes payments shouldn't be the same server.",[58,290,291,294,295,299],{},[18,292,293],{},"The SAP identity at hop 2."," Run its composite authorizations through the SoD ruleset you already own, as though it were a person. A conflict there is a ",[26,296,298],{"href":297},"\u002Fblog\u002Ffour-eyes-and-segregation-of-duties-for-ai-agents","design defect",", whatever the tool list says, because a tool list can change in a deployment and an SAP role is what the auditor tests.",[15,301,302,303,305,306,308,309,312,313,242],{},"The specification adds a layer on top, but it's advisory. There ",[18,304,67],{}," always be a human in the loop with the ability to deny tool invocations. Clients ",[18,307,67],{}," prompt for confirmation on sensitive operations and show tool inputs before calling. Servers ",[18,310,311],{},"must"," validate inputs, implement proper access controls and rate-limit. Those are good requirements. But the client-side ones are only as reliable as whichever client connects, which is why the release of anything that moves money belongs in SAP's own approval path and ",[26,314,316],{"href":315},"\u002Fblog\u002Fcan-an-ai-agent-approve-its-own-payment","not in the agent layer",[32,318,320],{"id":319},"logging-three-logs-one-record","Logging: three logs, one record",[15,322,323],{},"An agent calling SAP through MCP produces up to three logs, and only one of them is evidence.",[98,325,326,339],{},[101,327,328],{},[104,329,330,333,336],{},[107,331,332],{},"Log",[107,334,335],{},"Written by",[107,337,338],{},"What it is",[117,340,341,355,366],{},[104,342,343,346,349],{},[122,344,345],{},"Client tool-usage log",[122,347,348],{},"The agent host",[122,350,351,352,354],{},"The specification says clients ",[18,353,67],{}," log tool usage for audit purposes. It's the agent's account of itself",[104,356,357,360,363],{},[122,358,359],{},"MCP server log",[122,361,362],{},"Your integration",[122,364,365],{},"What the server was asked, and what it sent on to SAP",[104,367,368,371,374],{},[122,369,370],{},"SAP's own record",[122,372,373],{},"The system of record",[122,375,376],{},"The document, its created-by field, its change history",[15,378,379,380,383,384,242],{},"The protocol is candid about the first. The 2026-07-28 revision ",[18,381,382],{},"deprecated MCP's own Logging feature",", suggesting stderr or OpenTelemetry instead. It was never an audit mechanism, and nothing in MCP produces evidence of what SAP did. That evidence is SAP's own record, and the MCP logs become useful only when ",[26,385,387],{"href":386},"\u002Fblog\u002Fai-agent-logs-are-not-an-audit-trail","reconciled against it",[15,389,390],{},"Make that reconciliation cheap from the first release. Have every write tool return the SAP document number and log it in the MCP server alongside the requester, the tool, the inputs and the hop-2 identity. The specification documents OpenTelemetry trace context propagation through request metadata, which helps correlate client, server and downstream call, but the join that matters to an auditor is the one to the SAP document.",[32,392,394],{"id":393},"what-mcp-solves-and-what-it-doesnt","What MCP solves, and what it doesn't",[98,396,397,407],{},[101,398,399],{},[104,400,401,404],{},[107,402,403],{},"MCP solves",[107,405,406],{},"MCP leaves to you",[117,408,409,417,425,433,441],{},[104,410,411,414],{},[122,412,413],{},"A standard way to describe, discover and call tools",[122,415,416],{},"Which tools exist, and which are allowed to write",[104,418,419,422],{},[122,420,421],{},"OAuth 2.1 protection of an HTTP MCP server, with audience-bound tokens",[122,423,424],{},"Which SAP identity the server uses at hop 2",[104,426,427,430],{},[122,428,429],{},"A ban on token passthrough",[122,431,432],{},"How the requester's identity reaches SAP, if at all",[104,434,435,438],{},[122,436,437],{},"Portability across agent platforms",[122,439,440],{},"SAP authorization checks, SoD, release steps, evidence",[104,442,443,446],{},[122,444,445],{},"Guidance on human confirmation and input validation",[122,447,448],{},"Enforcing either for a client you don't control",[15,450,451,452,455],{},"Nothing about the protocol changes the ",[26,453,454],{"href":28},"indirect-access licensing question"," either: an agent creating documents through an MCP server is still a non-human source creating documents.",[15,457,458,459,462,463,466,467,470],{},"One more distinction avoids a common confusion. SAP does publish MCP servers, for example ",[211,460,461],{},"@sap-ux\u002Ffiori-mcp-server",", which runs over STDIO to help AI coding assistants create and modify Fiori apps, and ",[211,464,465],{},"@cap-js\u002Fmcp-server"," for CAP projects. Those are ",[18,468,469],{},"developer tools",". They help build applications. They aren't a governed runtime entry point to finance data, and their existence doesn't answer any of the hop-2 or hop-3 questions above.",[32,472,474],{"id":473},"what-i-would-decide","What I would decide",[55,476,477,480,483,486,489,492],{},[58,478,479],{},"Put an MCP server in front of SAP only with a written tool list: one verb, one scope, and no generic query or call-anything tools.",[58,481,482],{},"At hop 2, use principal propagation or an agent-specific SAP user bounded by the requester, and never a shared technical user for anything that writes.",[58,484,485],{},"Expose released BAPIs and OData services, and review any custom wrapper's authorization checks before it ships.",[58,487,488],{},"Run the hop-2 identity through the SoD ruleset as though it were a person.",[58,490,491],{},"Keep release of payments and postings in SAP's own approval path, with a second human.",[58,493,494],{},"Return and log the SAP document number on every write, so the MCP log can be reconciled to the system of record.",[15,496,497],{},"MCP is a good protocol for a narrow job, and the specification is careful about the edge of that job. The mistake is assuming the protocol's authorization story continues past that edge. It stops at the MCP server, and SAP's starts at the next logon.",[15,499,500],{},[501,502,503,504,508,509,242],"em",{},"See also ",[26,505,507],{"href":506},"\u002Fblog\u002Fhow-ai-agents-fit-into-existing-enterprise-systems","how AI agents fit into existing enterprise systems"," and ",[26,510,512],{"href":511},"\u002Fblog\u002Fenterprise-ai-agent-security-boundaries","security boundaries for enterprise AI agents",{"title":514,"searchDepth":515,"depth":515,"links":516},"",2,[517,518,519,520,521,522,523,524],{"id":34,"depth":515,"text":35},{"id":95,"depth":515,"text":96},{"id":158,"depth":515,"text":159},{"id":200,"depth":515,"text":201},{"id":272,"depth":515,"text":273},{"id":319,"depth":515,"text":320},{"id":393,"depth":515,"text":394},{"id":473,"depth":515,"text":474},"architecture",null,false,"2026-09-25","An MCP server adds a hop, not a control. Where authorization, segregation of duties and logging live when an agent calls SAP through MCP, and what MCP solves.","md",[532,535,538,541],{"question":533,"answer":534},"Does an MCP server handle authorization for SAP?","No. The MCP specification covers how an MCP client authenticates to the MCP server, using OAuth 2.1 for HTTP-based transports with tokens bound to that server as their audience. It explicitly forbids the server from passing that token on: a call from the MCP server to an upstream API such as SAP uses a separate credential. SAP then checks its own authorization objects against whatever user that credential logs on as. Authorization for the business action therefore lives in SAP and in the identity choice at that second hop, not in MCP.",{"question":536,"answer":537},"Should an MCP server call SAP as a technical user or with principal propagation?","Principal propagation, or an agent-specific user bounded by the requester, for anything beyond low-risk reads. A single technical user makes every requester look the same to SAP: the documents name the integration, the SAP authorization checks run against the union of rights the technical user holds, and revoking it stops everything at once. Principal propagation carries the requesting person's identity into SAP so the existing roles apply, which is the model SAP itself describes for Joule; its cost is that the agent inherits that person's full rights and the documents name someone who did not click.",{"question":539,"answer":540},"Is an MCP server log an audit trail for SAP postings?","No. It is the integration's account of what it asked for, written by the component under review. The specification recommends that clients log tool usage for audit purposes and deprecated its own protocol logging feature in the 2026-07-28 revision in favour of stderr or OpenTelemetry, so nothing in MCP produces evidence of what SAP did. The evidence is SAP's own record, the documents and their change history, and the MCP log becomes useful when it is reconciled against that record using the document numbers SAP returned.",{"question":542,"answer":543},"What does MCP actually solve for enterprise integration?","A standard way for an agent to discover and call tools, with schema-described inputs and outputs, and a standard OAuth-based way to protect an HTTP-based MCP server with audience-bound tokens. That makes an integration portable across agent platforms. It does not decide which SAP identity is used, which authorizations apply, how segregation of duties is enforced, which steps need human release, or how the action is evidenced. Those remain design decisions on the SAP side.",{},10,true,2.55,"\u002Fblog\u002Fmcp-server-sap-authorization","enterprise-ai-systems","MCP server SAP",240,"Model Context Protocol specification revision 2026-07-28 (authorization, security considerations, tools, changelog), read from the specification source; ABAP authorization behaviour as described in SAP's ABAP cheat sheet for the SAP BTP ABAP Environment; Joule principal propagation as described by SAP; SAP's open-source Fiori and CAP MCP servers as published. Checked on 2026-09-25 through the specification source and cross-checked excerpts of the listed sources. SAP-side object names beyond these are deliberately not listed: verify the authorization objects your own BAPIs and OData services check.","Trigger-based: re-verify when a new MCP specification revision is published or when SAP ships a governed MCP endpoint for S\u002F4HANA. The architecture argument is durable; the protocol details are versioned.","editorial-and-factual","reviewed","Tan Gravam","informational",{"title":5,"description":529},[560,563,566,569,572,575,578,581,584],{"title":561,"url":562,"accessed":528},"Model Context Protocol — Specification 2026-07-28: Authorization","https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2026-07-28\u002Fbasic\u002Fauthorization",{"title":564,"url":565,"accessed":528},"Model Context Protocol — Specification 2026-07-28: Authorization security considerations (token passthrough, upstream APIs)","https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2026-07-28\u002Fbasic\u002Fauthorization\u002Fsecurity-considerations",{"title":567,"url":568,"accessed":528},"Model Context Protocol — Specification 2026-07-28: Tools (human in the loop, untrusted annotations, security considerations)","https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2026-07-28\u002Fserver\u002Ftools",{"title":570,"url":571,"accessed":528},"Model Context Protocol — Specification 2026-07-28: Key Changes (Logging deprecated)","https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2026-07-28\u002Fchangelog",{"title":573,"url":574,"accessed":528},"SAP-samples — ABAP cheat sheets: Authorization Checks","https:\u002F\u002Fgithub.com\u002FSAP-samples\u002Fabap-cheat-sheets\u002Fblob\u002Fmain\u002F25_Authorization_Checks.md",{"title":576,"url":577,"accessed":528},"SAP Community (SAP) — From Prompt to Permission: How Joule Securely Accesses SAP Cloud ERP Private","https:\u002F\u002Fcommunity.sap.com\u002Ft5\u002Ftechnology-blog-posts-by-sap\u002Ffrom-prompt-to-permission-how-joule-securely-accesses-sap-cloud-erp-private\u002Fba-p\u002F14480012",{"title":579,"url":580,"accessed":528},"SAP Community (SAP) — Joule A2A: Propagate the User Identity from Joule into S\u002F4HANA","https:\u002F\u002Fcommunity.sap.com\u002Ft5\u002Ftechnology-blog-posts-by-sap\u002Fjoule-a2a-propagate-the-user-identity-from-joule-into-s-4hana\u002Fba-p\u002F14420290",{"title":582,"url":583,"accessed":528},"SAP open-ux-tools — @sap-ux\u002Ffiori-mcp-server README","https:\u002F\u002Fgithub.com\u002FSAP\u002Fopen-ux-tools\u002Ftree\u002Fmain\u002Fpackages\u002Ffiori-mcp-server",{"title":585,"url":586,"accessed":528},"cap-js — @cap-js\u002Fmcp-server README","https:\u002F\u002Fgithub.com\u002Fcap-js\u002Fmcp-server","blog\u002Fmcp-server-sap-authorization",[589,590,591,592],"enterprise-ai","ai-agents","sap","integration","text","DoOQtkO3EGupwurX0Wa8BFG9nB4BI0G_PkBVlpzFdcc",{"related":596,"bridge":526,"next":606,"place":609},[597,600,603],{"path":511,"title":598,"description":599},"Security Boundaries for Enterprise AI Agents","An agent that reads untrusted content can be instructed by it. What the boundaries are, which of them hold under pressure, and which are theatre.",{"path":297,"title":601,"description":602},"Four-Eyes and Segregation of Duties for AI Agents","A human clicking approve on an agent's proposal is not a second pair of eyes. What independence requires when one of the two parties is a model.",{"path":315,"title":604,"description":605},"Can an AI Agent Approve Its Own Payment?","It is not a new question. It is a release strategy — and the per-transaction limit everyone reaches for is the one an agent defeats first.",{"path":165,"title":607,"description":608},"Agent Identity: Who Is the AI Acting As?","Delegated, shared, agent-specific or temporary — the four identities an AI agent can act under, and what each one costs you in attribution and blast radius.",{"label":610,"position":611,"total":612,"hub":613},"Architecture",7,8,"\u002Ftopics\u002Fenterprise-ai-systems#cluster-architecture",1790367446154]