The short answer
AWS has turned Security Hub into a multicloud, AI-aware security control plane, generally available since 14 July 2026. It now natively monitors Microsoft Azure virtual machines, container images, Function Apps and identities against the CIS Azure Foundations Benchmark, surfacing those findings in the same console and workflows as AWS findings. Alongside it, GuardDuty AI Protection went GA for Amazon Bedrock and SageMaker, flagging anomalous model invocations, prompt-injection attempts and credential-driven "cost harvesting," with an AI inventory and a preview of AI-powered investigations layered on top.
For teams running workloads on more than one cloud — which is most of them — the practical win is fewer blind spots and one place to triage risk. The deeper signal is that AI workloads are now a first-class attack surface with their own failure modes, and the major clouds are racing to instrument them. Neither shift removes your own security work; both raise the bar on what "we have visibility" is supposed to mean.
What did AWS actually ship?
The headline change is that Security Hub — AWS's service for collecting and prioritizing security findings — is no longer AWS-only. Its multicloud capabilities for Microsoft Azure are now generally available to all customers, letting Security Hub natively discover and monitor Azure resources such as virtual machines, container images, Function Apps and user identities. Those resources are evaluated against the CIS Azure Foundations Benchmark, and their findings arrive in the same format, automation and response workflows as AWS findings, so a security team can assess risk across both clouds through one interface. Azure resources are priced at the equivalent AWS rates with no separate fee.
The second change targets AI. GuardDuty AI Protection, also generally available with a 30-day free trial, watches for anomalous model invocations on Amazon Bedrock and SageMaker, integrates with Bedrock Guardrails to catch prompt-injection attempts, and looks for "cost harvesting" — where stolen credentials are used to run up large bills on expensive foundation models. AWS paired this with an AI inventory in Security Hub that discovers AI assets organization-wide, from managed Bedrock, SageMaker and AgentCore usage to self-hosted models running on EC2, ECS and EKS and external model endpoints. For teams standing up their first AI and data workloads, that inventory is the difference between guessing where models run and knowing. A preview of GuardDuty AI-powered investigations, live in ten AWS Regions, uses AI agents to triage alerts and map them to MITRE ATT&CK.
AWS framed the move as filling a gap rather than closing the market. "Security Hub reaches across cloud providers, starting with Azure and expanding from there," said Michael Fuller, AWS Director of Security Services, who also cast the core problem as one of speed and correlation: "The hard part is understanding them, connecting them and acting before an attacker does, and doing it at the speed attacks now move." That reflects where cloud security operations actually hurt — not a shortage of alerts, but the effort of stitching signals from many tools into a single, actionable picture. Teams that run mostly on AWS but keep a foothold in Azure are the immediate audience.
Why does multicloud, AI-aware security matter now?
Two structural trends make this land. The first is that multicloud is the default, not the exception. Acquisitions, team preferences, best-of-breed services and regional requirements all push companies onto more than one provider, and each cloud has traditionally come with its own security tooling and its own console. Every extra pane of glass is a place where a misconfiguration hides and where an alert goes unseen because nobody owns that screen. A native cross-cloud view — even a first version that starts with Azure — attacks that fragmentation directly.
The second is that generative-AI workloads have become a real, exploitable surface with failure modes that classic tooling was never built to see. Prompt injection can turn a model or an agent into an unwitting insider; an over-permissioned model endpoint can leak data; and cost harvesting shows how quickly a stolen key converts into a five- or six-figure inference bill, because the resource being abused is expensive on purpose. Instrumenting Bedrock and SageMaker for exactly these patterns acknowledges that "secure the VM and the network" no longer covers the whole attack surface when part of your stack is a foundation model.
It is worth being precise about scope. This is a meaningful expansion, not a universal multicloud security platform: coverage starts with a defined set of Azure resource types and benchmark checks, Google Cloud is not in this release, and the deepest AI detections are anchored to AWS's own model services. The direction of travel is clear, and rival platforms will answer, but teams should size the capability to what it covers today rather than to the marketing category it points at.
What does this change in your stack?
The first thing it changes is your excuse for blind spots. If you run production workloads on both AWS and Azure and have been correlating their security posture by hand — or not at all — there is now a native path to a single view, and auditors will increasingly expect you to use something like it. Consolidated findings, common workflows and a shared benchmark make "we didn't see it in the other console" a weaker answer after an incident. That is a good pressure to be under, but it is pressure: someone has to enable the coverage, tune the benchmark exceptions and actually work the queue.
The second is that your AI workloads are now inventoried and watched in ways that expose gaps you may not have mapped. An AI inventory that surfaces self-hosted models on EC2, ECS and EKS, plus external endpoints, will almost certainly find model usage that grew organically outside your security review. Detecting prompt injection and cost harvesting is valuable, but it also makes visible how much of your AI footprint runs with broad permissions and thin monitoring. For regulated FinTech and healthcare teams, that inventory intersects directly with GDPR, SOC 2 and data-residency obligations — knowing where models run and what they can touch is now a compliance artifact, not just an ops nicety. This is where a focused security audit of your AI and multicloud perimeter pays for itself.
The third risk is the quiet one: mistaking a dashboard for a defense. A single-pane view reduces alert fatigue and blind spots, but the shared-responsibility model has not moved. Native detection does not configure least-privilege access, segment a network, rotate a leaked key or contain an incident. Vendor consolidation also carries its own trade-off — deeper integration with one provider's ecosystem can quietly raise the cost of staying genuinely multicloud. The capability is real; the work it implies is still yours.
What it means for US & EU software teams
If you already run on AWS and touch Azure, this is a low-friction upgrade worth piloting deliberately. Turn on Security Hub's Azure coverage for a non-critical subscription first, confirm the CIS benchmark findings map to owners and remediation paths you actually have, and decide where a genuinely cross-cloud view fits against any best-of-breed CNAPP you already run. The 30-day free trial on GuardDuty AI Protection is a clean way to measure signal-to-noise on your real Bedrock and SageMaker traffic before committing.
If you build AI features, treat the AI inventory as a forcing function. Use it to enumerate every place a model runs — managed and self-hosted — then close the obvious gaps: least-privilege on model endpoints, guardrails against prompt injection, tight credential hygiene and alerting on anomalous invocations and spend. Cost harvesting is a reminder that an AI key is now a bearer of real money, and should be protected like one. Folding these controls into your enterprise security baseline early is far cheaper than retrofitting them after an incident or an audit finding.
There is a delivery read, too. Consolidated tooling only helps if someone owns the console, tunes the rules and works the findings; a security service nobody watches is just a bigger bill. Teams that build a standing capability to run cloud posture and AI security as routine work — in-house or through a dedicated engineering team — turn launches like this into a configuration change. Teams that bolt on tools without owners turn them into shelfware and are surprised when the gap they thought was covered opens under an incident.
What to do this week
Turn the announcement into a short, concrete posture pass rather than a procurement debate.
- Map your clouds and owners. List every AWS and Azure account in production and name who owns security findings for each — you cannot consolidate what you have not inventoried.
- Pilot Azure coverage. Enable Security Hub's Azure monitoring on one low-risk subscription and check the CIS benchmark findings against real remediation paths.
- Trial AI Protection. Use the 30-day GuardDuty AI Protection trial on live Bedrock/SageMaker traffic to gauge signal quality and catch anomalous invocations.
- Run the AI inventory. Enumerate managed and self-hosted models, including on EC2/ECS/EKS and external endpoints, and flag anything running with broad permissions.
- Lock down AI credentials. Rotate and scope model-access keys, enforce least privilege on endpoints, and add alerting on unusual invocation volume and spend.
- Decide the tooling boundary. Choose deliberately where a cross-cloud view replaces or complements existing best-of-breed security tools, and avoid duplicate consoles nobody watches.
A cross-cloud security console with native AI-threat detection is a real step toward matching tooling to how software is actually built and run today. Teams that pilot it deliberately, keep clear ownership and treat AI workloads as a first-class attack surface will absorb news like this as a routine improvement. Teams that assume a new dashboard equals new security will learn, the hard way, that visibility and defense are not the same thing.
Frequently asked questions
What did AWS add to Security Hub?
On 14 July 2026 AWS made Security Hub's multicloud capabilities generally available for Microsoft Azure, so the service can now natively discover and monitor Azure virtual machines, container images, Function Apps and identities, evaluating them against the CIS Azure Foundations Benchmark. Azure findings use the same format, automation and response workflows as AWS findings and appear in one interface. AWS also added GuardDuty AI Protection and an AI inventory in Security Hub, extending coverage from AWS-only to a multicloud, AI-aware view.
What is AI cost harvesting?
Cost harvesting is an attack where someone uses stolen cloud credentials to invoke expensive foundation models — for example on Amazon Bedrock or SageMaker — and run up large inference bills, often to resell that access. Inference is costly and in high demand, so compromised credentials convert straight into value without the attacker deploying any infrastructure. GuardDuty AI Protection analyzes activity such as CloudTrail records to flag anomalous model invocations that indicate this abuse.
Does a single security dashboard remove my own responsibility?
No. Consolidating findings from AWS and Azure into one console reduces alert fatigue and blind spots, but the shared-responsibility model still applies. You are responsible for enabling the coverage, tuning the benchmarks, triaging and remediating findings, and securing the AI workloads themselves. A single pane of glass improves visibility; it does not configure least-privilege access, patch a misconfiguration or contain an incident for you.
Which parts are generally available versus preview?
Security Hub's Azure multicloud monitoring, GuardDuty AI Protection and the Security Hub AI inventory are generally available; GuardDuty AI Protection includes a 30-day free trial, and the AI inventory is part of Security Hub Essentials at no additional cost. GuardDuty AI-powered investigations, which use AI agents to triage alerts and map them to MITRE ATT&CK, are in preview in ten AWS Regions at launch. Azure resources are billed at the equivalent AWS rates.
Sources
AWS Security Blog — Security Hub adds AI workload protection and multicloud support for Microsoft Azure
SiliconANGLE — AWS Security Hub expands coverage to Microsoft Azure and beefs up AI protections
Help Net Security — AWS retools Security Hub for AI and multicloud threats