AI has quietly become part of everyday business infrastructure. Teams are using coding agents, foundation models, third-party APIs, and self-hosted models to build and run software — often without anyone keeping a full list of what’s actually in use.
That’s the real problem AWS is trying to solve. Not “is AI safe,” but a more basic question: does your security team even know where AI is running across your company?
One team might be using Amazon Bedrock. Another might have an open-source model running on an EC2 instance nobody flagged. A third might be quietly calling an outside AI API from inside an app. Without a full inventory, security teams can’t protect what they can’t see.
AWS’s answer is a three-part strategy: Security Hub AI Inventory, AWS Continuum, and Amazon GuardDuty AI Protection. Together, they’re meant to cover the whole lifecycle — knowing what AI you have, checking whether it’s configured safely, fixing what’s vulnerable, and watching for attacks in real time.
The newest piece, AI Inventory, gives teams a live, centralized view of the AI and machine-learning resources running across their AWS accounts. AWS includes it with Security Hub Essentials at no extra charge (see AWS’s announcement).
Here’s how the whole system fits together.
What Is AWS Security Hub AI Inventory?
AI Inventory exists to answer one question: what AI is actually running in our environment?
It pulls together AWS-managed AI services, supported self-hosted AI workloads, and even some external AI endpoints into a single view. If you’re managing AI across multiple AWS accounts, that’s a much clearer picture than trying to track it manually.
AWS also links each discovered resource back to its underlying infrastructure and security context — so it’s not just a list of names, it’s a list you can actually act on.
Why This Kind of Visibility Actually Matters
Old-school cloud inventories were built for a world where “assets” meant servers and databases. AI doesn’t fit that mold. A single company might be running managed models, open-source models, AI agents, coding assistants, and external APIs all at once — a mess often called AI sprawl.
The core issue is simple: you can’t secure something you don’t know exists.
AI agents make this worse. Unlike a normal app, an agent might have permission to touch your repositories, cloud services, databases, or internal tools. A poorly governed agent isn’t just a model risk — it’s a potential doorway into everything it’s connected to.
AI Inventory gives security teams a starting point: a map of what’s out there and how it connects to everything else.
How AWS Actually Finds All This AI
Discovery works differently depending on how the AI is deployed.
Managed AI services For things like Amazon Bedrock, Bedrock AgentCore, and SageMaker, Security Hub leans on AWS Config data. This is the easy case, since these resources already live inside AWS’s managed environment.
Self-hosted AI Trickier. A team could spin up an open-source model directly on EC2 without ever touching a managed AI service. To catch this, Security Hub uses software bill-of-materials data from Amazon Inspector to spot models, inference endpoints, and agents running on EC2 instances and ECR container images the kind of AI that would otherwise look like ordinary compute.
External AI APIs For AI called from outside AWS entirely, Security Hub can use Amazon GuardDuty’s DNS telemetry to spot known external AI endpoints being accessed by EC2 workloads. This can surface AI dependencies your official software inventory doesn’t even know about.
Is It Actually Free?
Mostly, yes but with a catch worth knowing.
AI Inventory itself doesn’t cost anything extra on top of Security Hub Essentials. However, some of the discovery methods lean on other AWS services: self-hosted discovery depends on Amazon Inspector, and external endpoint discovery depends on GuardDuty. Those services have their own pricing.
So the honest summary is: the inventory feature is free, but some of what powers it isn’t. Worth factoring in when you’re budgeting for an AI security setup.
Knowing What Exists Is Only Step One
Finding an AI resource doesn’t tell you whether it’s set up safely. That’s where AWS’s new AI Security Best Practices standard comes in, part of Security Hub’s cloud security posture management (CSPM) tools.
It runs 31 automated checks against things like:
- Network isolation
- Encryption at rest and in transit
- VPC placement
- AWS KMS key usage
- Authorization settings
- Private container registry requirementsAWS Continuum: Turning Alerts Into Action
Discovery is one problem. The other is what happens after a scanner floods your team with findings — most security tools are good at generating alerts and bad at telling you which ones actually matter.
That’s what AWS Continuum is built for: discovering, prioritizing, validating, and remediating security risks within guardrails your team sets AWS’s launch announcement
For code vulnerabilities specifically, Continuum can pull in findings from your existing security tools plus its own scans, rank them using context about your environment and business, and then test whether a flagged vulnerability is actually exploitable inside an isolated sandbox — instead of just trusting the alert. Confirmed issues then move into your normal review and deployment process for fixing.
Worth noting: several of Continuum’s headline features, including code vulnerability scanning, launched in preview, not as fully finished, generally available tools.
Why This Matters More Now That AI Writes Code
AI coding tools have made writing software dramatically faster. Great for productivity — but it also means security teams have a lot more code to review, a lot faster than before.
AI-generated code can introduce the same old problems: risky patterns, shaky dependencies, weak configs, leaked credentials, overly broad permissions, insecure infrastructure setups, and supply-chain issues.
The point isn’t that AI-written code is inherently worse. It’s that it’s produced faster than most security processes were built to handle. Continuum’s approach — actually testing whether something is exploitable rather than flagging every possible issue — is meant to help teams focus on real problems instead of chasing noise.
Security Is Moving Into the Developer’s Workflow
AWS is also pushing security tools closer to where code actually gets written. The AWS Security Agent, now folded into Continuum, works with Kiro and Claude Code, and AWS has added integrations with GitLab, GitHub Enterprise, Bitbucket, and Confluence.
The bigger idea here: security shouldn’t be the last stop before deployment. It should be part of the process from the start while code is being designed, written, and tested, not just checked afterward.
Threat Modeling, Automated
Continuum can also generate threat models straight from design documents or source code, using the well-known STRIDE framework, which looks at:
- Spoofing
- Tampering
- Information disclosure
- Denial of service
- Elevation of privilege
Automating this can catch risks earlier and makes it realistic to re-run threat modeling every time an application changes, something teams often skip because it’s tedious to do by hand. That said, human review still matters, especially for complex systems where automated tools might miss business context a person would catch.
Watching for Trouble: GuardDuty AI Protection
Finding AI resources and checking their configuration is only useful up to a point, you also need to know if something’s actively being attacked or misused.
Amazon GuardDuty AI Protection extends threat detection to supported workloads built on Bedrock, Bedrock AgentCore, and SageMaker AI, watching for behavior that suggests misuse or compromise, including:
- Unusual model activity a sudden shift in usage patterns, unfamiliar identities, or odd request origins can signal stolen credentials.
- Cost harvesting if someone gets hold of your cloud credentials, they might run huge numbers of AI requests just to burn your compute budget, even without stealing any data.
- Prompt injection malicious input designed to trick a model or agent into ignoring its instructions, leaking information, or taking unsafe actions. GuardDuty can catch some of this when paired with supported Bedrock Guardrails setups.
Putting It All Together: Four Layers
It’s easier to understand AWS’s approach as four connected layers, each answering a different question:
- Visibility (Security Hub AI Inventory) — What AI exists?
- Posture (AI Security Best Practices) — Is it configured safely?
- Vulnerability management (AWS Continuum) — Which risks are real, and can they be exploited?
- Runtime detection (GuardDuty AI Protection) — Is something attacking it right now?
None of these layers does much on its own. The value comes from stacking them — going from “we found this” to “this is safe” to “this is a real risk” to “someone’s actively probing it.”
AWS Isn’t Betting on One Model
Notably, none of this requires standardizing on a single AI provider. A company could run Bedrock for one project, a self-hosted open-source model for another, and a third-party API somewhere else — and AWS’s discovery tools are built to find all three, not just its own services.
That matters because most companies aren’t building around a single AI vendor anymore. They’re mixing and matching, and security tooling needs to keep up with that reality rather than assume everything lives in one place.
What Developers and Security Teams Get Out of This
For developers, security checks are shifting earlier — happening while code is written, not just before it ships.
For security teams, the real win is context: AI Inventory shows what exists, Security Hub ties resources to findings, GuardDuty flags suspicious activity, and Continuum helps decide what’s actually worth fixing first.
None of these tools matter much in isolation. The value is in connecting visibility, posture, detection, and response into one picture which becomes more important every time a company adds another model, agent, or API to the mix.
What This Doesn’t Fix
None of this replaces actual governance. Companies still need to decide things like:
- Which AI services employees are allowed to use
- What data can be shared with outside models
- Who’s allowed to deploy AI agents, and with what permissions
- How AI-generated code gets reviewed
- How third-party models get approved
- Which AI decisions need a human in the loop
A technical inventory can tell you what’s running. It can’t tell you whether it should be running, or whether it fits your company’s risk tolerance. That’s still a people-and-policy problem, not something a dashboard solves.
Bottom Line
AWS Security Hub AI Inventory tackles a real and growing problem: most companies genuinely don’t know where all their AI is running. It’s included free with Security Hub Essentials, though some of the discovery methods behind it lean on paid services like Inspector and GuardDuty.
From there, AWS Continuum pushes vulnerability management toward smarter prioritization and actual exploit testing, while GuardDuty AI Protection watches for live threats against AI workloads.
Put together, these tools point at where enterprise AI security is headed: as companies pile on more models, agents, and AI-generated code, security can’t stay a final checkpoint it has to be built into every stage.
