SAP MCP Security Checklist: 7 Checks You Must Verify Before Connecting AI Agents

As Model Context Protocol (MCP) increasingly becomes the standard interface for AI Agents to connect to SAP systems, security design can no longer be treated as a post-launch patch. MCP enables Agents not only to read data but also to trigger business actions—this bidirectional capability brings integration efficiency while also opening up new attack surfaces.

Why MCP in SAP Environments Requires Separate Security Scrutiny

MCP's value proposition is straightforward: replace the multiple custom APIs of the past with a single protocol, let Agents automatically gain business context, and support bidirectional read-write operations. But it is precisely this "one interface to rule them all" design that concentrates the risks of privilege escalation, data exposure, prompt injection, and credential theft onto a single protocol layer.

In SAP scenarios, the problem becomes more complex. GDPR, CCPA, and industry compliance requirements mean personal data and regulated fields cannot freely enter model context; traditional SAP audit logs also struggle to directly track AI-driven operations. Security responsibility is effectively shared among three parties: SAP handles core system security and the foundational authorization framework, MCP implementers handle protocol-layer security and message validation, and enterprises themselves must bear application-layer access control, data classification, business rule validation, and monitoring/alerting.

Model Context Protocol (MCP) is a protocol standard proposed and open-sourced by Anthropic in late 2024 to standardize context exchange and tool invocation between LLMs/AI Agents and external systems. Its core is a "client-server" model: MCP Server encapsulates external system capabilities into three primitive types—tools, resources, and prompts—while MCP Client (typically the Agent runtime) communicates with the Server via JSON-RPC 2.0 messages. Compared to the past practice of building custom REST APIs for each system, MCP lets Agents discover and execute external actions using a unified invocation convention, and therefore inherently carries "bidirectional read-write" capability. This means that once an MCP Server connects to SAP, it effectively exposes a set of SAP transaction codes and RFC/ODATA capabilities to the model as tools—any design oversight at the protocol layer maps directly to operational risk on business systems.

Security Checklist to Verify Before Connecting

Authentication and Identity Federation

All human user access to MCP-related systems should enforce multi-factor authentication. Agent-to-SAP communication should use dedicated non-interactive service accounts, with certificate-based authentication preferred over passwords for service-to-service communication. OAuth 2.0 / OpenID Connect should be integrated with SAP Identity Authentication Services (IAS) or enterprise IdP, with SAML 2.0 for legacy system compatibility when necessary.

Permissions should be assigned through groups wherever possible rather than bound to individual accounts. JIT (Just-In-Time) access grants elevated privileges only when needed and for limited time windows. Session timeout, renewal, and termination processes, as well as account lockout policies, must be configured before go-live—otherwise service accounts can easily become entry points for brute-force attacks.

SAP Identity Authentication Service (IAS) is a cloud identity service on SAP BTP that provides SSO, MFA, social/enterprise IdP federation, and conditional access policies, and can serve as an OIDC/SAML IdP or proxy. JIT (Just-In-Time) access means permissions do not reside long-term on user or service accounts; instead, after strong authentication and approval, specific roles or authorization objects are temporarily granted within a limited time window and automatically revoked upon expiry. Non-interactive service accounts are account types designed for machine-to-machine communication, typically bound to client certificates rather than interactive passwords, avoiding MFA challenges while also eliminating the password exposure surface. In the SAP context, such accounts are typically federated with IAS through SAP Cloud Connector or BTP Destination to achieve an end-to-end identity chain from Agent runtime to S/4HANA.

Authorization and Least Privilege Design

SAP role design should follow the principle of "no permissions by default, add on demand," with object-level restrictions on tables, fields, and transaction codes. Time-window and geographic constraints can be added for sensitive operations.

MCP-specific authorization considerations deserve separate listing: tool allowlists should expose only the tools needed for the current use case rather than the entire server catalog; roll out read-only query tools first before considering write and posting tools; each Agent should use an independent identity instead of sharing a single integration account with near-SAP_ALL privileges; parameter boundaries should be enforced for plants, company codes, etc., rather than allowing arbitrary table queries; high-impact tools must require a human confirmation step outside the model; development and production environments must never share the same MCP endpoint or token.

Network Segmentation and Transport Security

MCP should terminate on a controlled reverse proxy, and AS ABAP MCP ports should not be directly exposed to the internet. Chat clients should prefer mTLS or short-lived OAuth tokens over long-lived static bearer tokens. Secrets should be stored in a vault and rotated on the same cadence as other service credentials. Agent hosts need outbound controls—Agents should not be free to access arbitrary SAP systems.

mTLS (mutual TLS) requires both client and server to present and verify certificates during the TLS handshake. Unlike one-way TLS, which only verifies server identity, mTLS ensures that only Agents holding trusted certificates can establish connections, making it particularly suitable for machine-to-machine communication between service accounts. Short-lived OAuth tokens typically refer to access tokens with validity periods ranging from minutes to hours, issued on demand via refresh token or client credentials flows, so that even if intercepted, the exploitable window is extremely short. The combined approach is: the Agent first proves its identity to IAS via mTLS, then exchanges for a short-term token to call the MCP Server, achieving the effect that credentials never persist and are invalidated upon leakage. In contrast, a long-lived static bearer token, once written into configuration or logs, is equivalent to a permanent key until rotated.

Data Protection and the Reality of Prompt Injection

It is necessary to explicitly classify which SAP fields can enter model context and mask personal and regulated data. Tool return results should be treated as untrusted text, because prompt injection may arrive through ticket descriptions or master data notes. Tools that execute arbitrary ABAP or shell should be disabled or strictly gated. For systems that sync conversations to third-party LLM APIs, DLP and outbound controls must remain enabled.

Logging, Monitoring, and SIEM

Logs should include Agent identity, tool name, parameters (after sanitization), result status, and correlation ID, and should be sent to SIEM. Alert rules should cover new tool appearances, permission changes, and spikes in write operations. By default, do not store full sensitive payloads, but retain sufficient audit history. Optionally use tools like LangFuse to trace LLM spans, but still be able to correlate back to SAP users or jobs.

SIEM (Security Information and Event Management) is a platform for centrally collecting, correlating, and analyzing security logs, such as Splunk, Microsoft Sentinel, IBM QRadar, etc. In MCP scenarios, SIEM's value lies in correlating Agent operation events with SAP-side audit logs and IdP authentication events. A correlation ID is a unique identifier that runs through the entire request chain—from user question, Agent decision, MCP tool invocation, to SAP transaction execution—and without it, it is impossible to map "a certain AI conversation" to "a certain SAP document change." LangFuse is an open-source LLM observability platform that can trace prompts, token usage, and tool invocation chains, but it records model-side spans and still needs to be connected with SAP-side user/job logs via correlation IDs to form a complete evidence chain.

Lightweight Red Team Testing

Basic verification does not require a nation-state budget: attempt to invoke prohibited tools via prompt injection; confirm that expired tokens fail closed; verify that production tokens cannot be accessed from laptops outside the mesh; test whether a low-privilege Agent can escalate privileges through tool chaining.

Common Failure Modes

Static bearer tokens left in MCP configurations on development laptops are the most common starting point—the remedy is to rotate immediately, migrate to short-lived OAuth, and revoke old tokens in IdP/SAP. "Temporary" broad tool lists that remain un-narrowed long-term require freezing new tool additions and re-certifying the allowlist against signed use cases.

DEV and PRD sharing a single MCP URL is equally dangerous—split endpoints, verify DNS and certificates, and fail closed when targeting the wrong environment. If logs lack correlation IDs, it is impossible to investigate Agent behavior in SIEM—fix instrumentation before expanding write tools. Shadow agents set up privately by project teams need quarterly inventory—unauthorized MCP access is an integration risk, not a productivity hack.

Audit-Ready Check Order

When the security team asks "are we ready," the answer should not be a demo video but should be presented in the following order: Agent service account identity and least-privilege SAP roles; default read-only, write-exception tool allowlist; network paths and separated DEV/PRD MCP endpoints; secret storage, token lifecycle, and rotation ownership; log/SIEM evidence with sample correlated events; disable/rollback drill within 15 minutes; and signed use case scope with explicit non-goals.

Skipping any step is not agility—it is unverified. MCP security is essentially the application of classic control design to a new protocol surface.

Go-Live Sign-Off Template for First Production MCP Connection

A signable checklist should include: use case and explicit non-goals; Agent identity, IdP groups, and SAP roles/authorization objects; tool allowlist with read/write classification; development and production network path diagrams; token lifecycle and rotation ownership; log destinations and alert subscribers; rollback plan to disable server/tools within 15 minutes; and sign-offs from security, Basis, and architects.

MCP's power comes from standardizing Agent access. Precisely because of this, it deserves a checklist, not a heroic demo. Only after identity, allowlists, segmentation, and logging are "boringly complete" should you connect Agents to SAP.

One-line Summary

MCP connecting to SAP brings bidirectional read-write capability and new attack surfaces, requiring a go-live sign-off checklist to enforce identity, least privilege, segmentation, and logging.

Paragraph Summary

The article notes that MCP is becoming the standard interface for AI Agents to connect to SAP systems, and its bidirectional read-write capability—while improving integration efficiency—concentrates risks such as privilege escalation, data exposure, prompt injection, and credential theft onto the protocol layer. SAP scenarios also add GDPR/CCPA compliance and audit tracking challenges, with security responsibility shared among SAP, MCP implementers, and enterprises. The article provides a pre-connection security checklist: MFA and identity federation, dedicated non-interactive service accounts, JIT access, default read-only tool allowlists, human confirmation for write tools, mTLS and short-lived tokens, field classification and prompt injection protection, SIEM logs with correlation IDs, and lightweight red team testing. Finally, it lists common failure modes, audit check order, and a signable go-live template, emphasizing that security is the reuse of classic controls on a new protocol surface, not a heroic demo.