{"slug": "test-the-denied-path-before-connecting-an-ai-agent-to-sap", "title": "Test the denied path before connecting an AI agent to SAP", "summary": "A developer outlines a design checklist for testing denied-path behavior before connecting an AI agent to SAP via MCP, arguing that a successful stock query proves a connection works but says little about whether it is safe for other users, plants or production systems. The checklist covers out-of-scope data requests, target systems outside the allowlist, expired sessions, direct calls to hidden operations, oversized result sets and prompt injection via retrieved business content, with the goal of demonstrating a correct refusal as clearly as a successful answer. The author stresses that MCP authorization does not replace SAP roles, authorization objects or application checks, and that approval, timeout and reconciliation cases need their own tests.", "body_md": "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.\n\nFor 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.\n\nUse 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.\n\nThen change one condition at a time:\n\n| Change to the request | Expected behavior | Evidence to inspect | \n|---|---|---|\n| 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 | \n| Choose a target system outside the configured allowlist | Reject before contacting that target | Denial event and absence of a downstream call | \n| Reuse an expired session | Reject authentication | Session validation outcome | \n| Call an operation hidden from the user's catalog directly | Enforce authorization again | Server decision, not only the visible catalog | \n| Request a much larger date range or result set | Reject or apply documented limits | Validated arguments and response size | \n| Include instructions inside retrieved business content | Treat that content as data | Subsequent tool choice and authorization decisions | \n\nThe 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.\n\nA 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.\n\nThe 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.\n\nA 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.\n\nMCP 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.\n\nFor 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.\n\nAn 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.\n\nRecord 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.\n\nThe practical release question is: can the team demonstrate a correct refusal as clearly as a successful answer?\n\nFor the wider architecture, see the [NeKuDos guide to permission-aware SAP MCP design](https://nekudos.com/permission-aware-sap-mcp-server/). The [MCP authorization specification](https://modelcontextprotocol.io/specification/latest/basic/authorization) describes the client-to-server access layer; the SAP permission boundary still needs its own design and verification.\n\nDisclosure: 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.", "url": "https://wpnews.pro/news/test-the-denied-path-before-connecting-an-ai-agent-to-sap", "canonical_source": "https://dev.to/serkanozcan/test-the-denied-path-before-connecting-an-ai-agent-to-sap-8od", "published_at": "2026-09-25 09:00:46+00:00", "updated_at": "2026-09-25 09:30:31.397731+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-safety", "ai-policy", "mlops"], "entities": ["SAP", "MCP", "NeKuDos"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/test-the-denied-path-before-connecting-an-ai-agent-to-sap", "markdown": "https://wpnews.pro/news/test-the-denied-path-before-connecting-an-ai-agent-to-sap.md", "text": "https://wpnews.pro/news/test-the-denied-path-before-connecting-an-ai-agent-to-sap.txt", "jsonld": "https://wpnews.pro/news/test-the-denied-path-before-connecting-an-ai-agent-to-sap.jsonld"}}