Skip to main content
CloudArq
lensbedrock
scopeagents · rag · data plane
moderead-only
bedrock security · aws · read-only audit

Your Bedrock stack has an attack surface. Most scanners can't see it.

A Bedrock deployment is more than a model call. It is agents with action groups, executor Lambdas with IAM roles, knowledge bases fed from S3 buckets, guardrails, invocation logs, and cross-region inference profiles — each one an ordinary AWS object that can be misconfigured in a very AI-specific way. This page maps that surface hop by hop, with the read-only check that audits each link.

Updated 2026-07-13 · ~6 minute read

17
checks on this map
193
total checks
3
attack chains mapped
0
agents installed
bedrock · attack surface

The Bedrock attack surface, mapped

Three chains cover most of what can go wrong: the agent chain (what a hijacked agent could do), the RAG chain (who can read or poison the corpus), and the data-plane chain (where prompts travel and who could read the trail). Every hop below is a configuration object CloudArq reads; every tag is a real check in the registry.

chain a · agent

The agent chain

Autonomy is an IAM problem.

bedrock agent01

The reasoning loop plans its own tool calls. Its real authority is whatever its tools can reach.

agent → action group02

A function with requireConfirmation off can fire its executor with no human approval — excessive agency by configuration.

bedrock_agent_unconfirmed_action
action group → executor lambda03

The Lambda runs whatever the agent decides, under the Lambda’s own execution role.

executor role → trust policy04

Who can sts:AssumeRole the role that drives the agent — Principal *, or an un-scoped cross-account trust.

bedrock_agent_role_trust
role → everything it reaches05

Every permission on that role is capability a hijacked agent would inherit — mapped read-only from IAM policy documents.

agentic_blast_radius
chain b · rag

The RAG chain

Your corpus is a bucket.

knowledge base01

Managed RAG: your documents are ingested, embedded, and handed to the model as context.

kb → s3 data source02

The retrieval corpus lives in an ordinary S3 bucket, governed by that bucket’s policy and ACLs.

who can read the bucket03

A bucket configured for public or cross-account read exposes the whole corpus your model answers from.

bedrock_kb_source_exposure
who can write the bucket04

Write ingress lets an outsider plant documents the KB will ingest — the poison-document, indirect-prompt-injection path. The same check classifies write exposure too.

bedrock_kb_source_exposure
kb → vector store05

An OpenSearch Serverless backend bills its OCU minimum whether the knowledge base is queried or not.

rag_vector_store_cost
chain c · data plane

The data-plane chain

Prompts leave a trail — or none.

model invocation01

Every prompt and completion in the account moves through this plane.

invocation → guardrails02

A guardrail missing content or PII filters is a parity gap between what you think is filtered and what the configuration filters.

bedrock_guardrail_parity
invocation → logging off03

Model-invocation logging disabled while Bedrock is in use means no audit trail for AI calls in that region.

bedrock_invocation_logging_off
logging → s3 log sink04

Logging on with a public sink bucket means the prompts and completions themselves are configured world-readable.

invocation_log_sink_exposure
invocation → inference profile05

An EU workload invoking a US or global cross-region profile can have its prompt routed out of region.

ai_cross_region_residency

Every hop is read from configuration APIs — agent definitions, bucket policies, IAM policy documents. Read-only; CloudArq never invokes an agent or a model.

bedrock agentcore

AgentCore — the surface you're migrating to

Amazon Bedrock Agents Classic — the three chains above — is closed to new customers as of July 30, 2026. Existing agents keep running: there is no end-of-life and no forced migration deadline. But new agentic workloads are built on Amazon Bedrock AgentCore, with its own runtimes, gateways, memory stores, and identity token vaults. CloudArq covers both — the Classic agents you run today and the AgentCore resources you build next. Every check below 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.

AgentCore Memory on an AWS-owned key

An AgentCore Memory store encrypted with an AWS-owned key instead of a customer-managed KMS key. The configuration leaves you no key policy, no rotation control, and no independent revocation over the store that holds an agent’s long-term memory. CloudArq reads the memory resource’s encryption configuration only — never the memory records themselves.

memory_no_cmk

Gateway execution role with a wildcard grant

An AgentCore Gateway execution role whose policy grants a wildcard action on a wildcard resource. Because the gateway brokers the tools an agent can call, that grant is the upper bound on what any agent behind it could reach — excessive agency by configuration, read from the IAM policy document.

gateway_privileged_role

Gateway metadata unencrypted

An AgentCore Gateway whose names, tool names, and logs are not encrypted with a customer-managed key. The gateway’s own metadata — the description of every tool an agent is wired to — sits on default encryption you do not control.

gateway_no_cmk

Runtime in public network mode

An AgentCore Runtime configured in PUBLIC network mode rather than VPC-isolated. The network mode permits egress that a VPC-only deployment would not — a capability stated from the runtime’s configuration, not from any observed traffic.

runtime_public_network

Runtime execution role with a wildcard grant

An AgentCore Runtime execution role carrying a wildcard grant. Whatever code runs in that runtime inherits it, so the grant is the blast radius a compromised runtime would have — mapped read-only from the role’s policy document.

runtime_privileged_role

Identity token vault on a service-managed key

An AgentCore Identity token vault — which stores the OAuth tokens and API keys agents use to reach other services — encrypted with a service-managed key instead of a customer-managed KMS key. CloudArq reads the vault’s encryption configuration only; the stored credentials are never read.

token_vault_no_cmk

The AgentCore checks live in the Max-tier AI Workload lens and land in the same read-only audit as the Classic chains above. Watch a scan surface them in the live demo — every finding with its severity, the exact resource, and a guided fix.

adjacent surfaces

The surfaces Bedrock teams also own

Most Bedrock teams run more AI than Bedrock. The same audit covers the two neighbors that most often carry the same class of risk.

Self-hosted model servers

A GPU or accelerator EC2 instance whose security group opens a known model-server port — Ollama 11434, Ray 8265, vLLM 8000 — to 0.0.0.0/0. CloudArq reads instance and security-group configuration only and never probes the port, so the finding is a labeled hypothesis about what the configuration would allow, never a confirmed running service.

exposed_self_hosted_inference_endpoint

SageMaker capture sinks

A SageMaker endpoint capturing live inference inputs and outputs to an S3 bucket that is configured public — the capture stream would be world-readable. The audit reads endpoint and bucket configuration only; the captured data itself is never read.

sagemaker_data_capture_pii_sink

The surface has a cost-and-abuse side too: the credential-abuse pattern known as LLMjacking — someone else's inference billed to your account — and the quieter burn of Provisioned Throughput left running with no commitment term. The same read-only audit covers the configuration side of both; read the dedicated pages on LLMjacking and the full AI Workload lens.

what cloudarq reads

What CloudArq reads — and what it refuses to guess

Read-only, no agents, never auto-fix

The same connection model as every CloudArq audit.

5 facts
  • connectA read-only IAM role assumed with an ExternalId — the same connection every CloudArq audit uses. No keys to paste, no agents to install.
  • readConfiguration APIs: agent and action-group definitions, knowledge-base and data-source settings, guardrail configuration, logging configuration, bucket policies and ACLs, IAM policy documents. Plus two metered reads — CloudWatch metrics (token counts as numbers), and a bounded CloudTrail probe that looks only at InvokeModel event NAMES, to prove Bedrock is actually in use before a finding says so. Never S3 object contents, never event payloads, never prompts or completions, never your documents.
  • partialWhen the role lacks a permission, the affected check reports one honest partial naming what it could not read. It never guesses a clean result and never fabricates a finding it cannot prove.
  • storeCloudArq never stores your credentials, application data, database contents, or S3 objects. Audit data is encrypted at rest and hosted in the EU (Helsinki).
  • fixDetection plus a guided fix — never auto-fix. The audit changes nothing; you review every remediation and run it yourself.
faq

Frequently asked

01Is the Bedrock audit read-only?
Yes. CloudArq connects through a read-only IAM role secured with an ExternalId and calls configuration APIs only. It never invokes your models or agents, never changes a setting, and remediation is a guided fix you run yourself — never auto-fix.
02Can CloudArq see our prompts or documents?
No. The audit never reads S3 object contents, so it cannot see knowledge-base documents, invocation logs, or captured inference data. It flags a bucket that is configured public or cross-account readable — a statement about the configuration, never about the data inside.
03What happens when the audit role lacks a permission?
The affected check reports an honest partial that names the missing permission instead of guessing. CloudArq never marks a resource clean that it could not read, and never invents a finding it cannot prove from the API response.
04Does this replace Bedrock Guardrails?
No — they solve different problems. Guardrails filter model inputs and outputs at runtime; CloudArq audits the configuration around the model, including whether a guardrail is missing content or PII filters. Run both.
05Is Amazon Bedrock Agents Classic being retired?
No. As of July 30, 2026, Bedrock Agents Classic is closed to new customers, but existing agents keep running — there is no announced end-of-life and no forced migration deadline. New agentic workloads are built on Amazon Bedrock AgentCore. CloudArq audits both: the Classic agents you run today and the AgentCore runtimes, gateways, memory stores, and identity token vaults you build next.
06Does CloudArq read our AgentCore agents’ memory or conversations?
No. The AgentCore checks read control-plane configuration only — encryption-key settings, network mode, and IAM execution-role policies. CloudArq never touches the data plane: agent conversations, memory records, and browser sessions are never read. A finding such as an AgentCore Memory store on an AWS-owned key describes the encryption configuration, never the memory inside it.
07Which AgentCore misconfigurations does CloudArq check?
The AgentCore checks cover the resources a new agentic workload introduces: an AgentCore Memory store not encrypted with a customer-managed key; a Gateway or Runtime execution role carrying a wildcard grant (excessive agency); a Gateway whose metadata is unencrypted; a Runtime left in public network mode instead of VPC-isolated; and an Identity token vault — holding agents’ OAuth tokens and API keys — on a service-managed key. Each reads configuration only and is part of the Max-tier AI Workload lens.
08Which Bedrock risks does a generic CSPM miss?
The ones that only appear when Bedrock resources are connected to the AWS objects behind them: an action group whose requireConfirmation is off, the IAM reach of an agent executor role, a knowledge-base data-source bucket writable by outsiders, an invocation-log sink configured public, an EU workload on a US inference profile. A bucket-level check alone does not know that bucket feeds a RAG corpus or holds your prompt logs.

Put your Bedrock stack on the map

The Bedrock-surface checks ship on the Max tier inside the same read-only audit that runs all 193 CloudArq checks. Connect a read-only IAM role, run the scan, and read your own chains — every finding with its severity, the exact resource, and a guided fix.