Security
Enterprise MCP Security: The Checklist Before You Connect Agents to SAP
A comprehensive guide to securing Model Context Protocol connections in SAP environments, covering authentication, authorization, data protection, and monitoring essentials.
As Model Context Protocol (MCP) becomes the standard way to connect AI agents to SAP systems, security can't be an afterthought. This checklist covers the essential protections every enterprise needs before exposing MCP-enabled agents to their SAP landscape—from authentication and authorization to data protection and monitoring.
Why MCP Security Demands Special Attention
Understanding the unique security considerations of MCP in enterprise SAP environments:
The MCP Value Proposition & Risk Profile
MCP transforms SAP integration by providing:
- Standardized Interface: Consistent way for agents to access SAP data and functions
- Reduced Integration Complexity: One protocol to rule them all (replaces multiple custom APIs)
- Real-Time Context: Agents receive relevant business context automatically
- Bidirectional Communication: Not just read access, but ability to trigger actions
- Extensibility: Easy to add new capabilities as business needs evolve
But this power introduces new risks:
- Privilege Escalation Potential: Agents might gain more access than intended
- Data Exposure Risks: Sensitive business information could be leaked
- Injection Vulnerabilities: Malicious prompts could manipulate SAP calls
- Credential Theft Targets: MCP endpoints become attractive attack surfaces
- Privacy Regulation Challenges: GDPR, CCPA, and industry-specific requirements
- Audit Trail Complexity: Tracking AI-driven actions through traditional logs
The Shared Responsibility Model for MCP
Security is divided between SAP, the MCP implementation, and the consuming organization:
SAP's Responsibilities
- Core system security
- Base authorization framework
- Audit logging foundation
- Secure communication channels
MCP Implementation Responsibilities
- Protocol-level security
- Message validation and sanitization
- Secure session management
- Standardized error handling
Your Responsibilities
- Application-layer access controls
- Data classification and protection
- Custom validation and business rules
- Monitoring, alerting, and incident response
The MCP Security Checklist: Pre-Connection Essentials
What every organization must verify before deploying MCP-connected agents:
Authentication & Identity Verification
The foundation of secure access:
Strong Authentication Mechanisms
- Multi-Factor Authentication (MFA): Required for all human users accessing MCP-enabled systems
- Service Accounts: Use dedicated, non-interactive accounts for agent-to-SAP communication
- Certificate-Based Authentication: Preferred over passwords for service-to-service communication
- OAuth 2.0/OpenID Connect: Leverage SAP Identity Authentication Services (IAS) or enterprise IdP
- Just-In-Time (JIT) Access: Grant elevated privileges only when needed and for limited duration
- Passwordless Options: Consider FIDO2/WebAuthn for compatible environments
Identity Federation & Single Sign-On
- Central Identity Provider: All MCP connections should validate against enterprise IdP (Azure AD, Okta, Ping)
- SAML 2.0 Support: For legacy systems that don't support modern OAuth flows
- SCIM Provisioning: Automated user lifecycle management
- Group-Based Access: Assign permissions through groups, not individual users
- Session Management: Proper timeout, renewal, and termination procedures
- Account Lockout Policies: Protect against brute force attacks
Authorization & Access Control
Ensuring least privilege access:
Role Design Principles
- Minimal Required Permissions: Start with no access, add only what's explicitly needed
- Object-Level Security: Restrict access to specific tables, fields, and transactions
- Time-Based Restrictions: Limit sensitive operations to business hours when possible
- Geographic Constraints: Limit access to approved locations/networks
- Action Whitelisting: Specify exactly which function modules, BAPIs, or OData services can be called
- Read vs. Write Separation: Different roles for query-only vs. transactional operations
- Regular Access Reviews: Quarterly validation that permissions remain appropriate
MCP-Specific Authorization Considerations
- Tool allowlists: Expose only the MCP tools required for the use case — not the full server catalog.
- Read-only first: Ship query/metadata tools before any write/transport/posting tools.
- Per-agent identities: One agent ≠ shared “integration” user with SAP_ALL-adjacent rights.
- Parameter constraints: Bound plant, company code, or client where possible — not free-text “any table.”
- Human approval gates: High-impact tools require an explicit confirmation step outside the model.
- Dev vs prod servers: Never share the same MCP endpoint or token across landscapes.
Network Segmentation & Transport Security
- Terminate MCP on a controlled reverse proxy; no direct internet exposure of AS ABAP MCP ports
- Prefer mTLS or short-lived OAuth tokens over long-lived static bearer tokens in chat clients
- Store secrets in a vault; rotate on the same cadence as other service credentials
- Egress-control agent hosts — agents should not freely reach arbitrary SAP systems
Data Protection & Prompt Injection Reality
- Classify which SAP fields may enter model context; mask personal and regulated data
- Treat tool results as untrusted text — injection can arrive via ticket descriptions or master data notes
- Disable or strictly gate tools that execute arbitrary ABAP or shell
- Keep DLP / egress controls on systems that sync conversations to third-party LLM APIs
Logging, Monitoring & SIEM
- Log agent identity, tool name, parameters (redacted), result status, and correlation IDs
- Ship to SIEM; alert on new tools, privilege changes, and spike in write operations
- Retain enough history for audit without storing full sensitive payloads by default
- Optional: LangFuse / tracing for LLM spans — still correlate back to SAP user/job
Red Team Basics (Without a Nation-State Budget)
- Attempt prompt injection that tries to call disallowed tools
- Verify expired tokens fail closed
- Confirm prod tokens cannot hit from a laptop outside the mesh
- Test that a compromised low-privilege agent cannot escalate via tool chaining
Common Failure Modes (And What to Do)
- Static bearer token in a developer laptop MCP config: Rotate immediately; move to short-lived OAuth; revoke the old token in IdP/SAP.
- “Temporary” broad tool list that never narrowed: Freeze new tools; re-certify allowlist against the signed use case.
- One MCP URL for DEV and PRD: Split endpoints; confirm DNS and certs; fail closed if wrong landscape is targeted.
- Logs without correlation IDs: You cannot investigate an agent action in SIEM — fix instrumentation before expanding write tools.
- Shadow agents spun by project teams: Inventory quarterly; unauthorized MCP is an integration, not a productivity tip.
Checklist Order That Survives Audit
When security asks “are we ready?”, answer in this order — not with a demo recording:
- Identity and least-privilege SAP roles for the agent service account
- Tool allowlist with read-only default and named write exceptions
- Network path + separate DEV/PRD MCP endpoints
- Secret storage, token lifetime, and rotation owner
- Logging/SIEM proof with a sample correlated event
- Disable/rollback drill timed under fifteen minutes
- Signed use-case scope (and explicit non-goals)
Skip a step and you are not “agile” — you are unverified. MCP security is mostly classical control design applied to a new protocol surface.
Sign-Off Template: First Production MCP Connection
- Use case and explicit non-goals
- Agent identity, IdP group, and SAP role/auth objects
- Tool allowlist + read/write classification
- Network path diagram (dev vs prod)
- Token lifetime and rotation owner
- Logging destination and alert subscribers
- Rollback: how to disable the server/tools in <15 minutes
- Security + Basis + Architect signatures
MCP is powerful because it standardizes agent access. That is exactly why it deserves a checklist — not a hero demo. Connect agents to SAP only after identity, allowlists, segmentation, and logging are boringly complete.
