Topic starter
10/06/2026 11:29 pm
TL;DR: Cloud security now has to govern AI workloads as runtime identities, not just infrastructure assets, and Orca Security says its strategic collaboration agreement with AWS is designed to improve visibility, prioritization, and AI-assisted remediation for cloud and AI services running on AWS, with joint customers already citing faster risk response and clearer context for security decisions.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Orca Security Signs Strategic Collaboration Agreement with AWS to Advance AI-Powered Cloud Security”.
Key questions
Q: How should teams prioritise cloud risks in AI workloads on AWS?
A: Prioritisation should combine workload identity, data exposure, and business impact rather than relying on raw severity scores alone.
Q: Why do traditional cloud security approaches struggle with AI services?
A: They often surface findings without enough runtime context to show how the workload is built, configured, and used.
Q: What do security teams get wrong about AI-powered remediation for NHIs?
A: Teams often assume that faster remediation is automatically safer.
Practitioner guidance
- Map AI workloads to identity and access paths Identify how AI services on AWS inherit permissions, touch data, and interact with cloud resources so that risk decisions are based on runtime identity rather than asset labels.
- Enrich findings with business context Require remediation workflows to show which AI service, data flow, or business process is affected before an issue is assigned for action.
- Shift controls into CI/CD gates Introduce checks earlier in cloud delivery so misconfiguration and excessive access are caught before AI services reach production.
Bottom line: AI services on AWS force cloud security teams to govern runtime context, not just static posture.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
12/06/2026 5:34 am
AI-powered cloud security is becoming an identity governance problem, not just a posture problem. Once AI services are deployed on AWS, the question is no longer only whether a resource is misconfigured. It is also who or what can act through that service, how quickly those permissions change, and whether teams can explain the business impact of the risk. That makes cloud security, IAM, and workload identity governance part of the same operational control plane.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How do IAM and data security teams align on AI governance?
A: They should align around the same control objective: explainable access to sensitive data. IAM teams own entitlements and identity review, while data teams own classification and lineage, but AI risk emerges where those controls overlap. The best programmes treat access path visibility as a shared requirement.
👉 Read our full editorial: AWS collaboration sharpens cloud AI security and remediation workflows
This post was modified 1 day ago by NHI Mgmt Group