AI Workload Security on AWS: a lens over your audit
CloudArq's AI Workload lens is a view over your read-only AWS audit that surfaces the security and cost risk specific to AI workloads — Bedrock agents, RAG, guardrails, cross-region residency, and runaway spend. It is not a separate scanner and not a new category: each finding still counts toward its real Security or Cost pillar. For the wider AWS bill beyond AI, pair it with the AWS cost optimization audit.
Updated 2026-06-29 · ~6 minute read
What the AI Workload lens is
The AI Workload lens is a view — a computed is_ai_workload flag — over findings you already get from your CloudArq audit. When a finding touches an AI workload (a Bedrock agent, a Knowledge Base, a guardrail, an inference profile), the lens surfaces it together with the others, so you can read your AI risk in one place.
It is not a separate scanner and not a seventh category. Every finding the lens shows still counts toward its real Security or Cost pillar in your score — the lens just gives that subset a name.
Bedrock Agents Classic and Amazon Bedrock AgentCore
Amazon Bedrock Agents Classic is closed to new customers as of July 30, 2026 — existing agents keep running, with no end-of-life and no migration deadline — and new agentic workloads are built on Amazon Bedrock AgentCore. The AI Workload lens covers both: the Classic agents you run today (their blast radius, role trust, guardrail parity, and invocation logging, detailed on Bedrock agent security) and the AgentCore runtimes, gateways, memory, and identity you are moving to.
For AgentCore the lens reads control-plane configuration only — encryption keys, network mode, and IAM execution roles — never the data plane that holds agent conversations, memory records, or browser sessions. It surfaces an AgentCore Runtime left in public network mode instead of VPC isolation; a Runtime or Gateway execution role that grants a wildcard action on a wildcard resource (excessive agency); and AgentCore Memory, a Gateway, or the Identity token vault that holds agents' OAuth and API-key credentials encrypted with an AWS-owned or service-managed key rather than a customer-managed KMS key. Each finding describes what a misconfiguration would permit — an upper bound — never an observed attack.
This is AI security posture management (AI-SPM) delivered as a lens over your read-only AWS audit — the same connection and the same guided fix, not a separate platform to run. See it on a sample account in the live demo.
The 20 AI Workload checks
Each check describes a capability the read-only audit can surface — what a misconfiguration would expose or cost — never an observed attack or an asserted violation.
Agentic blast radius
Maps the IAM blast radius a compromised Bedrock agent could reach through its action-group Lambda execution role: the capability it would have, not whether it has been abused.
AI cross-region data residency
Flags an EU Bedrock workload that invoked a US or global inference profile — that profile can route the prompt to a US region. CloudArq never inspects the payload and never asserts a violation.
RAG vector-store cost
Spots a Bedrock Knowledge Base on OpenSearch Serverless paying the ~$350/mo 2-OCU minimum when S3 Vectors or pgvector would usually be far cheaper for a small knowledge base.
Bedrock guardrail parity
Finds Bedrock guardrails missing baseline content / PII protection — configuration gaps, not a claim that CloudArq catches unshielded model calls.
RAG source exposure
Flags a Knowledge Base whose S3 data-source bucket is configured for public or cross-account read — or for untrusted WRITE, letting anyone inject poisoned documents into the corpus the model retrieves. CloudArq reads only bucket configuration, never the objects, and never claims anything was accessed or uploaded.
Agent role trust
Reads the trust policy of the role that drives the agent and flags who can sts:AssumeRole it — Principal *, an un-scoped cross-account principal. A configuration read, never evidence that anyone assumed the role.
AI audit trail off
Flags a region where Bedrock model-invocation logging is disabled while the account actively uses Bedrock — no audit trail for AI calls. CloudArq proves logging is off and Bedrock is in use; the unlogged calls are exactly what it cannot see.
Bedrock cost optimization
Surfaces the standard Bedrock cost levers when spend is meaningful — including measured prompt-cache utilisation from CloudWatch cache-token metrics (advisory only when caching is provably not engaged); deeper model-specific guidance needs invocation logging, which the finding states plainly.
Runaway-agent anomaly
Catches a Lambda recursive loop via AWS's RecursiveInvocationsDropped metric — a runaway-agent cost and anomaly signal. CloudArq reads the metric; it does not inspect agent reasoning.
Provisioned Throughput burn
Flags a Bedrock Provisioned Throughput running with no commitment term — billed hourly at the full on-demand rate with no discount, whether the model is invoked or not. CloudArq reads the config; it never invents a dollar figure.
Agent excessive agency
Finds a Bedrock agent with action-group functions whose requireConfirmation is off — it can invoke its executor Lambda with no human approval. A configuration read; the Lambda is named, never invoked.
Exposed self-hosted LLM
Correlates a GPU/accelerator EC2 instance that is internet-reachable on a known model-server port (Ollama 11434, Ray 8265, vLLM 8000) — a likely self-hosted LLM anyone on the internet can reach. CloudArq reads config only and never probes the port, so the framework is a labeled hypothesis.
Invocation-log sink exposure
Flags Bedrock invocation logging whose S3 sink bucket is configured public — with body delivery on, those logs hold the actual prompts and completions. CloudArq reads only bucket configuration, never the log contents.
SageMaker capture sink exposure
Flags a SageMaker endpoint capturing inference data to a public S3 bucket — the live inputs and outputs are world-readable. Bucket configuration only; the captured data is never read.
AgentCore memory encryption
Flags an Amazon Bedrock AgentCore Memory store encrypted with an AWS-owned key rather than a customer-managed KMS key. Long-term agent memory retains the facts and summaries an agent extracts from conversations; CloudArq reads the encryption configuration only, never the stored records.
AgentCore gateway role privilege
Reads the execution role an AgentCore Gateway uses to invoke its tools and targets, and flags a wildcard action-on-wildcard-resource grant — the capability a compromised gateway would have, not evidence it was abused.
AgentCore gateway encryption
Flags an AgentCore Gateway with no customer-managed KMS key — its names, tool names and CloudWatch logs are unencrypted by default. A configuration read of the control plane.
AgentCore runtime network isolation
Flags an AgentCore Runtime deployed in PUBLIC network mode rather than a VPC with private subnets — read from its network configuration. CloudArq reads the control-plane config, never the agent's traffic.
AgentCore runtime role privilege
Reads the execution role an AgentCore Runtime runs as and flags a wildcard grant — the upper bound of what a compromised agent could reach through the runtime's role. A static IAM read, never observed behaviour.
AgentCore token-vault encryption
Flags the AgentCore Identity token vault — which holds the OAuth and API-key credentials agents use — on a service-managed key rather than a customer-managed KMS key, when credential providers exist. CloudArq reads the vault's encryption configuration, never the stored secrets.
Several of these signals — an AI audit trail switched off, an exposed invocation-log sink, wildcard credential grants — are also the read-only tells of LLMjacking, the stolen-credential attack that runs up your Bedrock bill on someone else's traffic.
One agent's role can reach far past its job
The agentic blast-radius check maps the IAM a compromised Bedrock agent could reach through its action-group Lambda execution role — the capability, not an observed attack. Reachability is read from your IAM policy documents (managed and inline) and sts:AssumeRole grants — read-only; CloudArq never invokes your agent.
Read-only analysis. Reachability read from your IAM policy documents (managed + inline) and sts:AssumeRole — CloudArq never invokes your agent.
How it works
What the lens looks like in your audit
Illustrative only — sample rows, not a real account. Each finding keeps its real Security or Cost pillar and ships with a guided fix.
Frequently asked
- 01Is this a separate product or scanner?
- No. The AI Workload lens is a view over your existing CloudArq audit — a computed is_ai_workload flag on findings you already get. There is no separate scanner to install and no seventh category; every AI finding still counts toward its real Security or Cost pillar.
- 02Does CloudArq need write access to my AI workloads?
- No. CloudArq connects through a read-only IAM role secured with an ExternalId. It never stores your credentials, application data, database contents, or S3 objects, and the audit itself is read-only — detection plus a guided fix, never auto-fix.
- 03What is agentic blast radius?
- The set of AWS permissions a compromised Bedrock agent could reach through its action-group Lambda execution role — the reachable capability, not an observed attack. CloudArq maps what that role could do; it never claims the agent has been abused.
- 04Which tiers include the AI Workload checks?
- The AI Workload lens ships on the Max tier. See the pricing page for the full tier breakdown of which checks each plan includes.
- 05Does CloudArq scan Amazon Bedrock AgentCore?
- Yes. The AI Workload lens reads Amazon Bedrock AgentCore control-plane configuration, read-only, across AgentCore Runtime, Gateway, Memory, and the Identity token vault. It flags a Runtime left in public network mode instead of VPC isolation, a Runtime or Gateway execution role that grants a wildcard action on a wildcard resource, and AgentCore Memory, a Gateway, or the token vault encrypted with an AWS-owned or service-managed key rather than a customer-managed KMS key. It reads configuration only — encryption keys, network mode, IAM execution roles, and authorizer settings — never the data plane that holds agent conversations, memory records, or browser sessions.
- 06What happens to Bedrock Agents Classic after July 30, 2026?
- Amazon Bedrock Agents Classic is closed to new customers as of July 30, 2026. Existing agents keep running — there is no end-of-life and no migration deadline — and new agentic workloads are built on Amazon Bedrock AgentCore. CloudArq covers both, so the Classic agents you run today and the AgentCore workloads you build next are audited through the same read-only connection.
- 07Does scanning AgentCore mean CloudArq reads my agents' conversations or memory?
- No. The lens reads AgentCore control-plane configuration only — encryption keys, network mode, IAM execution roles, and authorizer settings. It never reads the data plane: agent conversations, AgentCore Memory records, or browser sessions. Every AgentCore finding describes what a misconfiguration would permit, never anything that was observed or accessed.