AI Changed the SAP Threat Model: Why Access + AI Is the New Access + Expertise
2026-02-26
sap grc security ai authorization risk s4hana sap-security access-risk mcp

AI Changed the SAP Threat Model: Access + AI Is the New Access + Expertise

For decades, SAP systems had an unintentional security advantage: they were complicated. Exploiting an SAP environment required not just system access but deep domain knowledge. You needed to know which transaction codes mattered, how authorization objects interacted, where sensitive data lived across modules, and which configuration gaps were actually exploitable. That knowledge took years to build. Most attackers didn't have it.

That barrier is gone.

With a large language model and basic SAP access, someone with no prior ERP experience can ask questions like "which authorization objects control payment runs" or "how do I check if a user has SAP_ALL" and get accurate, specific answers in seconds. The knowledge that used to live exclusively in the heads of senior Basis administrators and GRC consultants is now available to anyone with a browser.

This isn't speculation. The data already shows the shift happening. Average time-to-exploit for disclosed vulnerabilities dropped from 47 days to just 5 days in 2025. One documented espionage campaign automated roughly 80% of its attack activities using AI tools. And in the SAP world specifically, critical vulnerabilities like CVE-2025-42957 - an ABAP code injection flaw rated CVSS 9.9 - require only low-privileged access and low attack complexity. An attacker who gets in through such a vulnerability can escalate to SAP_ALL privileges and own the entire system.

The old equation was: access + expertise = threat. The new one is: access + AI = threat. And that changes what "good enough" access governance looks like.

What used to protect SAP systems (and no longer does)

SAP's complexity was always a double-edged sword. It made the systems hard to secure properly, but it also made them hard to attack. An outsider who compromised a user account still faced a steep learning curve:

Navigation: SAP has thousands of transaction codes. Knowing which ones matter - and how they chain together - took experience. An attacker who landed in the system would see a wall of menus and codes with no obvious path to valuable data.

Authorization logic: SAP's authorization model is unusually granular. Authorization objects, field values, activity types, organizational levels - understanding how these interact to determine what a user can actually do requires real expertise. Misconfigurations that grant excessive access aren't obvious unless you know exactly what to look for.

Data structures: Financial data in SAP isn't sitting in a single table labeled "payments." It's distributed across document types, posting keys, company codes, and clearing accounts. Extracting value from an SAP system requires knowing where to look and how the data relates.

Module interdependencies: SAP modules don't operate in isolation. A purchase order in MM triggers accounting entries in FI. A goods receipt affects inventory valuation. Understanding these chains - and how to exploit them - required cross-module knowledge that few people had.

All of this created what security people sometimes call "security through obscurity." Not real security, but a practical barrier that reduced the attacker pool to a handful of specialists.

AI demolished that barrier. A language model trained on SAP documentation, forum posts, blog articles, and technical notes can walk an attacker through any of the above in a conversational format. Step by step. With examples.

And that's just the passive version - asking an AI questions and copying the answers into a SAP GUI session. The active version is worse.

MCP servers turn AI from advisor into operator

The Model Context Protocol (MCP) lets AI models connect directly to external tools and data sources. An MCP server is a lightweight wrapper that exposes system capabilities - database queries, API calls, file operations - as tools the AI can invoke autonomously. Building one that talks to SAP through RFC or OData takes a competent developer a few hours.

Once that connection exists, the AI isn't just answering questions about SAP. It's inside SAP. It can query tables, call BAPIs, read authorization data, and chain operations together without the attacker ever opening a SAP GUI. The attacker describes a goal in plain language - "find users with payment run access who also have vendor master maintenance" - and the AI agent executes the queries, correlates the results, and reports back.

This matters because it removes the last manual bottleneck. Without MCP, an attacker still had to translate the AI's guidance into SAP actions one at a time. With an MCP server pointed at SAP, the AI handles that translation autonomously. The attacker becomes a project manager giving instructions to an agent that already knows how to operate the system.

Organizations building legitimate MCP integrations with SAP for internal automation face the same structural risk. Every MCP server connected to your SAP landscape is an access path. If the server's credentials are overprivileged, or if the server itself is reachable from outside your network, or if nobody bothered to restrict which BAPIs and tables it can access - you've given AI agents a door into your system that bypasses every authorization check your SAP security team carefully built.

How AI enables attacks that used to require SAP specialists

Consider what this looks like in practice.

Reconnaissance becomes trivial

An attacker with a compromised SAP account used to face a disorienting interface. Now they can describe what they see to an AI and get instant guidance: "I'm in SAP. I can run SE16. What tables contain vendor bank details?" or "How do I check what authorizations my user has?" The AI doesn't just answer - it provides transaction codes, table names, field descriptions, and step-by-step instructions. Connect that AI to SAP via MCP, and it does the lookups itself.

This turns a confused intruder into an effective one in minutes. Give them an MCP server, and it happens without the intruder touching SAP at all.

Exploit chains become accessible

SAP vulnerabilities rarely exist in isolation. Exploiting them typically requires chaining together multiple steps: find a misconfiguration, use it to access a specific function module, leverage that to escalate privileges, then use the elevated access to reach the target data. This kind of multi-step exploitation used to require a specialist who understood both the vulnerability and the SAP authorization model.

AI can map these chains. Given a starting point ("I have access to this RFC function module") and a goal ("I want to create a vendor master record"), a language model can reason through the intermediate steps. Hook it up to SAP through an MCP server, and it can try the steps too - probing for access, hitting dead ends, and adjusting its approach without the attacker needing to understand any of it. It won't always find a viable path, but it doesn't need to succeed every time. It just needs one.

Social engineering gets SAP-literate

Phishing emails targeting SAP users used to be generic. Now AI can generate messages that reference specific transaction codes, module names, and business processes relevant to the target's role. An email that says "Please review the updated GR/IR clearing run in MR11" is far more convincing to an SAP controller than a generic "click here to verify your account."

AI agents add a second layer of risk

Beyond AI-assisted human attackers, there's a growing risk from AI agents operating inside SAP environments themselves.

Organizations are deploying AI agents, copilots, and automation bots that interact with SAP systems through APIs, RFCs, and direct database access. A recent survey found that 92% of organizations lack full visibility into their AI identities and 95% doubt they could detect misuse if it occurred. Three out of four CISOs have discovered unsanctioned AI tools already running in their environments.

These agents create access risk in ways that traditional GRC frameworks weren't designed to handle:

Overprivileged service accounts. AI agents need system access to function. In practice, they often get broad access because it's easier to configure than precise, minimal permissions. A bot that needs to read purchase order data might end up with write access to vendor master records because someone assigned it a generic service role.

Shadow integrations. Proof-of-concept AI projects connect to SAP through API keys, RFC destinations, or MCP servers that bypass governance entirely. When the POC ends, the connections stay. Nobody decommissions the agent or its MCP server. Nobody reviews its access. That orphaned server is now an unmonitored door into your SAP system.

Behavioral unpredictability. A human user with transaction ME21N will create purchase orders. That's predictable. An AI agent with the same access might use it in ways nobody anticipated - querying data across modules, combining information from multiple sources, or triggering processes in unexpected sequences. Traditional usage monitoring doesn't catch these patterns because it wasn't built for autonomous, goal-seeking systems.

Delegation chains. AI agents increasingly call other AI agents. Agent A might have access to SAP and delegate a subtask to Agent B, which connects to an external system. The authorization chain becomes difficult to trace, and the effective access of the chain can exceed what any individual agent was granted.

Why granular access monitoring is no longer optional

Most organizations monitor SAP access at the wrong level of granularity.

They know which users have which roles. They run periodic SoD checks. They review SAP_ALL and SAP_NEW assignments. That was adequate when the threat model assumed attackers needed deep SAP knowledge. If only a handful of people in the world could exploit a specific authorization gap, you could afford to review it annually.

That assumption no longer holds. When AI makes every authorization gap potentially exploitable by anyone with system access, the monitoring has to get more specific.

Transaction-level monitoring isn't enough

Knowing that a user executed transaction FB01 tells you they posted a financial document. It doesn't tell you what they posted, whether the amount was unusual, whether they also ran F110 to trigger the payment, or whether the same user created the vendor they just paid. Those patterns - which indicate fraud or exploitation - only become visible when you analyze at the authorization object level and cross-reference with actual business data.

Authorization-object-level analysis is the minimum

Access risk analysis needs to operate at the level where SAP actually makes its access decisions: authorization objects and field values. That means understanding not just that a user has role Z_FI_CLERK, but that this role grants F_BKPF_BUK with ACTVT = 01 for company code 1000, and what that combination actually enables.

This is the level at which MTC Skopos operates. Every analysis - SoD conflicts, critical actions, did-do comparisons - works at the authorization object and field value level. When you combine that with usage data and change documents, you get a picture of not just what users can do, but what they actually do, and where the gaps between those two are widest.

Continuous beats periodic

Annual access reviews made sense when the threat landscape changed slowly. With AI-assisted attacks compressing exploitation timelines from weeks to hours, waiting twelve months between reviews leaves too much exposure. Monthly or even real-time monitoring of authorization changes, new role assignments, and usage anomalies is becoming table stakes.

Access risk is one piece of the puzzle - but it's the piece that enables everything else

To be clear: access risk management won't stop every AI-powered attack. Network intrusions, zero-day exploits, social engineering, supply chain compromises - these are all real vectors that require their own defenses. SAP security is a multi-layered problem involving patching, network segmentation, code scanning, logging, and incident response.

But access risk is the enabler. An attacker who gets into your network still can't do much in SAP without authorizations that let them reach sensitive data or execute sensitive transactions. A zero-day gets them through the door; it's the authorization profile of the compromised account that determines what they can do once inside. An AI agent probing your system via MCP is limited by the credentials its server holds.

Every attack scenario described in this article has the same prerequisite: access that's broader than it should be. Tightening that access won't make the other threats disappear, but it reduces the blast radius of every single one of them. That's why access risk sits at the center.

What this means for GRC teams (and how MTC Skopos helps)

First, stop deprioritizing authorization gaps because they require "specialist knowledge" to exploit. That knowledge is commodity now. Any user with system access and a language model can find weak spots in your authorization design. Treat every gap as exploitable.

MTC Skopos makes this practical. Its critical action analysis identifies exactly which users hold sensitive authorizations - not at the role level, but at the authorization object and field value level. When the STAR ruleset flags a user as having payment run capabilities, MTC Skopos tells you which authorization object, which field values, and which role grants it. That's the level of detail you need when the threat model assumes every gap will be found.

Second, track what users do, not just what they can do. The did-do gap - the difference between assigned access and used access - is both a cost problem (as we covered in FUE optimization) and a security problem. Every unused authorization is attack surface that serves no business purpose. MTC Skopos cross-references authorization assignments against transaction usage logs and change documents (CDHDR/CDPOS), so you can see which users hold sensitive access they never exercise. Removing those authorizations reduces your license costs and your exposure in one move.

Third, build SoD rulesets that reflect the AI threat model. Traditional SoD analysis catches users who can both create vendors and post payments. That's still important. But in a world where AI can chain operations across modules, you also need to look at authorization combinations that wouldn't concern you if a human held them but become dangerous when an AI agent can execute them at speed. MTC Skopos lets you build custom rulesets at any level of granularity - down to individual authorization object field values combined with specific transaction codes via SU24 integration.

Fourth, extend governance to non-human identities. AI agents, service accounts, MCP server credentials, and automation bots need the same access governance as human users. Probably stricter, given their ability to operate at machine speed. Analyze the service accounts and communication users in your SAP system through MTC Skopos the same way you'd analyze a human user's access. If a bot's service account holds more authorizations than a senior buyer, something is wrong.

And finally, treat your authorization data as a security asset. SU24 mappings, role structures, authorization traces - these aren't just compliance artifacts. They're the data that tells you where your system is exposed. MTC Skopos is built around this data: it ingests your role exports, SU24 tables, usage statistics, and change documents, and turns them into a picture of where assigned access exceeds actual need. Keeping that picture current is a security practice, not a GRC box-ticking exercise.

The uncomfortable truth is that SAP security was never really about complexity being a barrier. It was about the attacker pool being small. AI expanded that pool by orders of magnitude. The authorization gaps that existed last year still exist today - they just have a lot more people (and bots) who can find and exploit them.

Access risk management won't stop every attack. But it controls what any attacker - human or AI - can actually do once they're inside. That makes it the single highest-leverage control you have.

See your authorization risks at the level attackers see them

Start Free 14-Day Trial

Run SoD analysis, critical action reviews, and did-do comparisons at the authorization object level. Find the gaps before someone - or something - else does.

« All posts