AI agents are increasingly moving from answering questions to taking actions.
An agent may retrieve business data, create an order, update a business object, trigger an integration flow, or execute another enterprise operation on behalf of a user. This makes integration between AI agents and enterprise systems a particularly interesting architectural topic — but also a security-critical one.
In my previous discussion around agent integration, I referenced the SAP Integration Solution Advisory Methodology (ISA-M) and the different integration styles and use-case patterns for connecting agents with enterprise applications.
This article takes the discussion one step further.
What happens when the agent is not operated by SAP (Domain NON-SAP Agent to SAP), but is a custom agent running on a third-party platform such as Google Cloud, Microsoft Azure, AWS, IBM Cloud, or another AI platform?
And more importantly:
How do we protect SAP APIs and business processes when third-party AI agents can dynamically discover and execute enterprise capabilities?
This is where SAP Integration Suite, the SAP MCP Gateway, API Management policies, and the OWASP API Security Top 10 come together.
This article looks at this question from three perspectives:
- SAP Integration Suite and the SAP MCP Gateway as an integration and governance layer
- OWASP as a security framework
- The EU AI Act as an additional governance consideration for enterprise AI scenarios
____
The MCP Gateway as an Enterprise Boundary
Consider the architecture shown below.
On the right side, custom agents and AI clients operate on third-party platforms. On the left side are SAP business applications such as SAP S/4HANA, SAP SuccessFactors, SAP Business Data Cloud, SAP Concur, SAP Customer Experience, and SAP Business Network. Between these worlds sits the enterprise integration and security architecture.
This separation is important. The AI agent should not automatically become a trusted participant in the SAP landscape simply because it communicates using MCP. Instead, the transition between the agent network and the enterprise network should represent an explicit trust boundary. A useful architectural principle is therefore:
Treat an AI agent as an external consumer of enterprise capabilities — even when the agent itself is trusted.
The agent may be legitimate while a particular request is still incorrect, overly broad, unauthorized, malformed, or the result of unintended autonomous behavior.
____
Why OWASP Matters for MCP
MCP introduces a new consumer for enterprise APIs: the AI agent. However, many of the underlying security challenges are not entirely new. An MCP tool may ultimately result in an HTTP request against an API or an integration endpoint. Therefore, established API security principles continue to be highly relevant.
The OWASP API Security Top 10 2023 identifies the following risks:
Risk | OWASP API Security Risk |
API1 | Broken Object Level Authorization |
API2 | Broken Authentication |
API3 | Broken Object Property Level Authorization |
API4 | Unrestricted Resource Consumption |
API5 | Broken Function Level Authorization |
API6 | Unrestricted Access to Sensitive Business Flows |
API7 | Server Side Request Forgery |
API8 | Security Misconfiguration |
API9 | Improper Inventory Management |
API10 | Unsafe Consumption of APIs |
OWASP specifically highlights authorization as one of the biggest challenges in API security. For agent-based architectures, this becomes even more relevant because an agent can potentially select and invoke tools autonomously.
____
SAP API Policy as Part of the Security Layer
The SAP API Policy provides an important foundation for securely exposing SAP business capabilities to consumers, including AI agents. It defines principles and requirements for SAP APIs with the goal of enabling consistent, secure, and sustainable API consumption.
This remains relevant when APIs are exposed to agents through MCP. MCP introduces a new consumption model, but it should not bypass the governance principles applied to the underlying enterprise APIs.
For third-party custom agents, the combination becomes particularly important:
- SAP API Policy provides the governance principles for the underlying APIs.
- OWASP API Security Top 10 provides a framework for evaluating security risks.
- SAP MCP Gateway provides the controlled integration boundary for exposing these capabilities to agents.
The objective is not to expose every available API operation as an MCP tool. Instead, selected and governed business capabilities should be made available according to the agent's intended purpose. More details can be found in the SAP API Policy.
____
The EU AI Act: Security Meets AI Governance
Security is only one dimension of enterprise agent integration. Organizations operating in or providing AI systems into the European Union also need to consider the EU AI Act. The EU AI Act introduces a risk-based regulatory framework for AI systems. The obligations that apply depend on factors such as the role of the organization, the characteristics of the AI system, and the context in which it is used.
Therefore, using an MCP Gateway or connecting an AI agent to SAP does not automatically classify the resulting solution as a high-risk AI system.
The actual use case matters. An agent assisting an employee with retrieving product information is fundamentally different from an AI system used in areas classified as high-risk under the EU AI Act. Nevertheless, several principles behind the EU AI Act are highly relevant when designing enterprise agent architectures.
____
Conclusion
MCP makes enterprise capabilities accessible to AI agents through a standardized protocol. But standardizing access does not remove the need for enterprise integration principles.
Quite the opposite.
When third-party agents can dynamically discover and execute enterprise capabilities, security, governance, and observability become even more important. OWASP helps us evaluate the technical security of this boundary. The EU AI Act reminds us to look beyond technical security toward risk management, transparency, traceability, data governance, and human oversight where applicable. And ISA-M provides the architectural framework for deciding how these agent integrations should fit into the overall enterprise integration strategy.
The key principle remains simple:
Connecting an agent is easy. Integrating it securely and responsibly into the enterprise is the real architectural challenge.

