What Orca Security’s AWS Relationship Means for SAP Cloud Security

At SAP Sapphire 2026, AWS positioned itself around SAP migration acceleration, data access, AI development, and sovereign cloud deployment. Its announcements included new work tied to RISE with SAP, SAP Business Data Cloud Connect for Amazon Athena, Amazon Bedrock, and MCP-based agent connectivity.

AWS’s expanding SAP role creates a broader security question for customers using the hyperscaler as part of their ERP transformation. As SAP environments connect more directly with cloud infrastructure, AI services, and live business data, security teams need visibility into risks that sit outside the traditional SAP application layer.

That is where Orca Security’s AWS relationship becomes relevant. The company signed a Strategic Collaboration Agreement with AWS earlier this year, with Orca Security’s AI remediation capabilities running on Amazon Bedrock. The agreement points SAP customers toward a security layer around AWS-based modernization, where identity, workload, data, and AI risks may increasingly shape ERP security programs.

SAP Modernization Expands Security Responsibility

SAP modernization on AWS is creating a wider operational environment around ERP systems. The core SAP application remains central, but more of the activity around it now runs through cloud-native services that handle migration, connectivity, analytics, AI development, and data access.

That changes how security teams need to think about responsibility. A SAP environment on AWS can include identities, permissions, storage, network paths, development pipelines, APIs, and runtime workloads that sit outside the SAP application itself. Some of those controls may be managed by SAP, AWS, partners, or customer teams, depending on the deployment model. The practical challenge is knowing where those boundaries sit before risk turns into a governance gap.

AI adds another layer. As SAP data becomes more accessible to analytics tools and agentic AI services, security teams need to understand which systems can reach that data, how access is governed, and where activity is logged. SAP security now also requires visibility into the cloud environment around the application, where services, identities, data flows, and workloads increasingly support ERP modernization.

Orca Security Brings AWS Context to SAP Risk

Orca Security’s AWS agreement ties its cloud security platform to the AWS layer becoming more important to SAP modernization. The agreement aligns Orca Security’s cloud-native application protection platform with AWS’s AI and security ecosystem, including Amazon Bedrock for AI remediation and AWS Marketplace for procurement.

Orca Security is an AWS Security Competency partner, with integrations across Amazon GuardDuty, AWS CloudTrail, AWS Security Hub, and AWS Organizations. That places its platform in the operational layer where SAP-adjacent cloud risks can emerge, including identity activity, workload exposure, and audit trails.

Orca Security’s agentless architecture is also relevant to SAP environments. Orca Security’s SideScanning technology checks cloud workloads from outside the running systems, rather than requiring security agents to be installed on each workload. That addresses a common operational concern in SAP estates, where production systems can be sensitive to additional host-level software and change management overhead.

AI Activity Raises SAP Visibility Requirements

AWS’s Sapphire announcements point to an architecture in which AI agents, Amazon Bedrock, MCP servers, and SAP integration services can work together around ERP systems. That creates a visibility requirement beyond traditional SAP application controls.

The security concern becomes visibility. When AI services begin working with SAP-connected data, risk can emerge in the cloud environment around the application rather than inside SAP alone. Security teams need to see that activity clearly enough to understand how data, access, and runtime behavior are changing.

Orca Security’s March 2026 platform update connects to that problem. The update added Runtime AI Threat Detection, which is designed to identify when workloads, identities, and processes interact with AI models, MCP servers, and third-party AI tools. As SAP customers use AWS to support AI development around ERP systems, that kind of visibility becomes a practical requirement for understanding risk in the cloud environment around SAP.

What This Means for SAPinsiders

• Security ownership will need clearer mapping. SAP customers moving deeper into AWS may need to revisit internal ownership between Basis, cloud security, GRC, and platform teams. The risk is not only technical exposure, but unclear accountability when ERP-connected activity crosses application and cloud boundaries.
• AI governance needs runtime evidence. Policies for AI use around SAP data will carry limited value if teams cannot observe how AI services behave in cloud environments. Runtime visibility can help turn AI governance into an operational control model.
• Vendor evaluation should follow architecture. SAP customers should assess cloud security tools against the architectures they are actually building, rather than against legacy SAP security categories. As ERP modernization expands into AWS services, relevance may come from cloud context, identity visibility, and AI activity monitoring.