Is 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.

Can 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.

What 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.

Does 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.

Which 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.

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

checks on this map

160

total checks

attack chains mapped

agents installed

Start free scan See the 30-sec demo →

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.

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 only: agent and action-group definitions, knowledge-base and data-source settings, guardrail configuration, logging configuration, bucket policies and ACLs, IAM policy documents. Never S3 object contents, 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.
05Which 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 185 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.

Start free scan See the 30-sec demo →