Building a Permission-Aware SAP MCP Server: Tool Design, Authorization and Audit Logs

When someone asks an AI assistant to “show the open purchase orders for plant 1000,” the request sounds simple. The server has harder questions to answer: May this user see that plant? Are prices in scope? Which SAP system should receive the call? Can the result be reused in another conversation?

An SAP MCP Server is not secure merely because it can connect to SAP. It becomes trustworthy when it can re-evaluate identity, permission, target system and data scope on every tool call.

This guide explains how to move from a working demo to a production-minded design: how to bound tools, where to enforce authorization, when to require a human decision and what to record without turning the audit trail into a second sensitive-data store.

What is a permission-aware SAP MCP Server?

A permission-aware SAP MCP Server checks more than whether a person has signed in. It evaluates the caller, role, target SAP system, requested tool, data scope and potential impact together. It rejects unauthorized calls before they reach SAP, preserves SAP-side authorization for allowed calls and records the decision in a form an operator or auditor can later understand.

The distinction matters. The MCP authorization specification defines an access framework between clients and MCP servers. It does not replace SAP PFCG roles, authorization objects, organizational levels or application-specific checks.

A valid access token proves something about the session. It does not mean that the person may perform every operation in SAP.

Start with the threat model

Before naming tools, write down what a bad day looks like. At minimum, consider these risks:

• A user asks for company-code or plant data that their SAP role does not permit.
• The model misunderstands a legitimate request and generates parameters that are much broader than intended.
• Instruction-like text inside a document persuades the agent to invoke a different tool.
• A broadly privileged shared technical user turns a small application mistake into wide SAP access.
• A write call appears to time out, is retried automatically and creates the same business object twice.
• Audit logs capture tokens, personal data or full business documents while trying to preserve evidence.

OWASP’s work on generative AI security also treats excessive agency, uncontrolled actions and sensitive-information disclosure as core risk areas. The OWASP GenAI Security Project is a useful source for the current taxonomy.

A threat model should not end as a workshop document. Link every material risk to a policy rule, a negative test and an operational signal.

Architecture: seven checks for one tool call

Breaking the production path into explicit stages makes gaps easier to see:

1. Authenticate the caller. Validate the session, token audience and scopes.
2. Reduce the tool catalog. Expose only the tools that make sense for the user’s role, environment and use case.
3. Make a policy decision. Evaluate the user + tool + target system + arguments + context together.
4. Resolve the SAP principal. Use on-behalf-of access where it is supported; otherwise constrain the technical identity and add application-level controls.
5. Collect approval when required. Do not execute consequential financial, master-data or authorization changes without the appropriate human decision.
6. Filter the result. Select the fields the task needs, mask sensitive values and enforce row limits before returning data to the model.
7. Record the decision. Produce a useful audit event for both allowed and denied calls without logging unnecessary business content.

These controls cannot live only in the system prompt. “Do not call this tool when the user lacks permission” is behavioral guidance, not an authorization boundary.

Tool design: narrow, explicit and single-purpose

The production MCP tool catalog, tool names and input schemas are part of the product’s security and implementation design; they do not need to be published. The governing principle is that each operation should be narrow, have an explicit business purpose and produce one bounded effect. This allows each operation to have its own role mapping, input limits, approval rule and audit policy.

Public architecture material can use capability classes such as “read-only query,” “draft preparation” and “approved persistent action.” Production names, descriptions, schemas and SAP object mappings should remain private.

Separate read, prepare and commit

A single tool that reads context, creates a document and commits it can look convenient. When something goes wrong, it is difficult to tell which step happened. A safer sequence separates the effects:

1. A read tool retrieves the required context.
2. A preparation tool builds a draft and shows the proposed change.
3. A commit tool applies the change using an approval reference.

For write operations, use a unique duplicate-prevention mechanism. A network timeout should not turn a retry into a second business document.

Constrain the argument space

An operation should accept only the fields it needs. Instead of accepting open-ended commands, queries or service names:

• Select the SAP system and client from a server-side allowlist.
• Limit business inputs to a closed, validated schema.
• Set maximum date ranges, row counts and page sizes.
• Restrict which record types and fields an operation can change.
• Reject unknown arguments instead of quietly ignoring them.

The tool description tells the model what the tool does. The schema limits what the model can ask it to do. Server policy decides what the caller is allowed to do.

How should authorization be modeled?

A role check is a starting point, not the whole decision. Evaluate at least four components together:

A purchasing specialist might run a read-only order query, for example, but only within the organizational scope they are authorized to access. A persistent write operation may still require a separate approval before anything is committed in production.

Where possible, execute the SAP call in the real user’s context so that existing SAP authorization remains effective. If a shared technical identity is unavoidable, do not compensate by giving it a broad role. Combine narrowly scoped services, target allowlists, organizational-level checks and short-lived credentials. Application policy should complement—not replace—SAP-side AUTHORITY-CHECK logic or service permissions.

The conceptual order remains the same: establish identity and make the policy decision first, execute the allowed SAP operation second, then filter the output and record the decision. This order can be explained publicly while real policy objects, field names and implementation code remain private.

Where should human approval apply?

Approving every call makes the assistant unusable. Approving none hands consequential decisions to the model. Base the requirement on the effect of the tool:

An approval screen should say more than “Do you want to continue?” Show the target system, affected record and fields that will change. If the arguments change after approval, the previous approval must no longer be valid.

What belongs in the audit log?

A useful audit record can answer three questions months later: Who asked, why did the system allow or deny the request, and what happened in SAP?

The following fields are a practical starting point:

• Unique event and trace identifiers
• Timestamp and environment
• A pseudonymous reference to the user or service identity
• Internal operation identifier and version
• Target SAP system and client
• Policy decision and reason code
• Approval reference and decision time, when applicable
• A non-sensitive summary or hash of important arguments
• SAP result class, transaction reference and duration
• Output masking or filtering policy applied

Do not log the complete user prompt, full conversation, access token, password or entire SAP document by default. Auditability and data minimization belong in the same design.

Send security events to storage where changes are prevented or detectable, and decide retention, time synchronization and access roles before production. An application log, an SAP change document and a security audit event are not the same record. A shared traceId should connect them when an investigation requires the full path.

Public examples should not reveal real operation identifiers, target-system names, reason codes or field schemas. Keep those details in internal documentation available only to authorized teams.

Seven mistakes that repeatedly cause trouble

1. Treating tool visibility as authorization. Hiding a tool improves the experience; it does not replace server-side enforcement.
2. Running every call through a broadly privileged shared user. A small application flaw can become broad SAP access.
3. Relying on prompt rules. System instructions can be misunderstood or bypassed; policy must be enforced in code.
4. Combining reads and writes in one tool. The effect boundary and approval point become unclear.
5. Letting the model choose a production target. System, client and environment must come from a server-side allowlist.
6. Logging everything. The audit trail becomes a new repository of sensitive data.
7. Blindly retrying writes. A timeout can create the same business document twice.

Pre-production test checklist

Automate the denied cases as well as the happy path:

• Allowed and denied tools for every business role
• Company code, plant, purchasing organization and customer boundaries
• Separation of development, test and production targets
• Expired sessions and deactivated users
• Missing, modified or unrelated approval references
• Documents and user inputs containing prompt injection
• Bulk extraction and unusual pagination attempts
• Write retries after a network timeout
• Whether a masked response remains useful
• Audit completeness for allow, deny and error outcomes
• An emergency kill switch for a tool or target system

Do not stop at the HTTP status. Verify whether the SAP object was created, which principal created it, what happened on retry and whether the audit events can be correlated end to end.

Where does SAP Integration Suite fit?

SAP provides its own approach to exposing enterprise APIs to agents through MCP Server and MCP Gateway capabilities in Integration Suite. A gateway is an important layer for publishing, routing, traffic management and security controls. Use the official SAP MCP documentation for the current product capabilities.

The core questions remain the same regardless of product choice: What can the tool do? On whose behalf does it run? Which SAP data can it reach? When is human approval required? What evidence remains afterward?

Short answers

Does MCP replace SAP PFCG roles?

No. MCP standardizes tool discovery and invocation. SAP users, roles, authorization objects and organizational-level checks should remain effective.

Is hiding tools by role sufficient?

No. A filtered catalog reduces mistakes, but every request still needs server-side authorization to stop malformed or direct calls.

Can an SAP MCP Server use a technical user?

Yes, but prefer on-behalf-of access when the landscape supports it. If a technical user is required, keep its permissions narrow, validate the business-user context and make every call traceable.

Should the audit log contain the full user question?

Not by default. Record the structured fields needed to explain the decision; mask or omit personal data, credentials and unnecessary business content.

The MCP server is a decision point, not just a connector

A production-ready SAP MCP Server is not a bridge that grants a model unlimited SAP access. It becomes a trustworthy decision point when narrow tools, per-call policy, SAP-side authorization, human approval for consequential actions and a measured audit trail work together.

Explore the NeKu AI SAP MCP Server approach and its access modes, or talk to our SAP AI consulting team about defining tool and permission boundaries for your SAP landscape.