A successful stock query proves that a connection works. It tells you much less about whether that connection is safe for the next user, a different plant or a production system.
For an SAP MCP integration, I would make the denied cases part of the acceptance criteria before expanding the tool catalog. This is a design checklist, not a claim that a particular deployment has passed these tests.
Use a simple scenario: a purchasing user asks for open orders within their permitted organizational scope. Keep the test data synthetic and the environment disposable. Record the expected principal, target environment, allowed organizational scope and fields before running the request.
Then change one condition at a time:
| Change to the request | Expected behavior | Evidence to inspect |
|---|---|---|
| Request data outside the user's organizational scope | Deny the request or constrain it to the authorized scope under an explicit policy | Policy decision and returned records |
| Choose a target system outside the configured allowlist | Reject before contacting that target | Denial event and absence of a downstream call |
| Reuse an expired session | Reject authentication | Session validation outcome |
| Call an operation hidden from the user's catalog directly | Enforce authorization again | Server decision, not only the visible catalog |
| Request a much larger date range or result set | Reject or apply documented limits | Validated arguments and response size |
| Include instructions inside retrieved business content | Treat that content as data | Subsequent tool choice and authorization decisions |
The crucial distinction is between a convenient interface and an enforced boundary. Hiding an operation from discovery reduces mistakes. It does not authorize or deny a direct invocation. That decision belongs on the server for every call.
A read-only pilot does not need a persistent action just to look more impressive. If the use case genuinely requires writes, separate context retrieval, draft preparation and execution.
The approval should identify the target system and the exact proposed change. Test that changing the proposal after approval invalidates the old approval. Also test missing approvals, expired approvals and approvals belonging to another operation.
A timeout deserves its own case. The client may lose the response after SAP has already accepted the action. Before retrying, reconcile the original operation using the application's duplicate-prevention mechanism and the downstream business outcome. An HTTP error is not proof that nothing happened.
MCP authorization does not replace SAP roles, authorization objects or application checks. Where supported, execute in the real user's context. If a technical identity is necessary, constrain both that identity and the application policy.
For each allowed test, inspect the principal actually used in SAP. For each denied test, establish where the decision occurred. A denial at the application layer and a denial in SAP can both be useful evidence, but they explain different controls. An acceptance record needs the test case, expected outcome, actual outcome and a trace reference. It usually does not need the complete user prompt, credentials or a copy of the returned business document.
Record allow, deny and error outcomes with enough context to reconstruct the decision. Inspect masking and retention as part of the test. Otherwise, the test evidence itself can become an unnecessary store of sensitive data.
The practical release question is: can the team demonstrate a correct refusal as clearly as a successful answer?
For the wider architecture, see the NeKuDos guide to permission-aware SAP MCP design. The MCP authorization specification describes the client-to-server access layer; the SAP permission boundary still needs its own design and verification. Disclosure: This adaptation was prepared with an autonomous AI assistant from NeKuDos's published guide. Its examples are conceptual and do not expose production tool names, schemas or customer data.