One page, built to be pasted into Slack, Jira, or a change-management ticket. It describes the read-only IAM role we ask you to create, exactly what data leaves your account, how to remove access, and the audit trail — in the precise, non-overstated terms your security team should hold us to.
| Source | Why | Access level |
|---|---|---|
| Bedrock model invocation logs (your S3 log bucket) | Detect duplicate/retry calls, batch opportunities, caching gaps, cache-TTL churn | Read-only (s3:GetObject, s3:ListBucket on the log bucket/prefix) |
| CloudWatch Bedrock metrics / log groups | Spend and volume estimation when invocation logs are partial or empty | Read-only (cloudwatch:GetMetricData, logs:GetLogEvents scoped to Bedrock) |
sts:GetCallerIdentity |
Confirm we assumed the right role in the right account | Read-only identity check |
That is the entire surface. No Bedrock invoke, no model access, no other service.
No. This is a non-negotiable property of the product, not a setting. The cross-account role never holds a write action. We deliver fixes as diffs / pull requests your team applies — we advise and assist, we never act. If a future feature appeared to need write access, that feature would be wrong and we would not ship it.
Detectors run on hashes and counts only. Raw bodies are never persisted in our plane at any stage.
Today (design-partner stage): we read the invocation logs through the read-only role with your explicit disclosure. Where a log entry contains a body, it is hashed; the raw body is never stored on our side.
GA roadmap (not yet built — stated plainly): the production design runs an in-account processor so bodies are parsed inside your account and only hashes + aggregates ever cross the boundary. This in-account processor is the GA target and a release blocker for GA; it is not claimed to be live today.
We will not describe the GA design as if it already ships. If raw-body privacy is a hard requirement for your security team right now, tell us and we will scope the scan to logs that carry no inline bodies.
A single cross-account read-only role with:
sts:GetCallerIdentity. Nothing else.kms:Decrypt on that key only.We provide the exact policy JSON / CloudFormation template for your team to read before anyone clicks deploy.
Bedrock invocation logging is off by default. If yours is off, enabling it is optional and runs entirely under your team's deploy permissions via the CloudFormation custom resource — never under our role. Without logs we run a degraded, metrics-only estimate and tell you so. Any log groups the stack creates get a 7-day retention by default so logging never becomes a silent cost.
Delete the CloudFormation stack (or delete the role). That revokes the trust relationship immediately; we can no longer assume it. There is nothing left running in your account, and nothing to uninstall on our side.
Negligible. The scan is log reads and metric queries — request-priced cents, not dollars. The only ongoing item is optional 7-day-retention log storage if you enabled invocation logging for the scan. We turn down log retention by default specifically so this never compounds.
Every AssumeRole we make is recorded — fail-closed, before any data is read — and is
queryable per customer. On request you get a complete access log: which role, when, what was read. Our
copy is delete / update / overwrite-proof at the IAM layer and point-in-time-recoverable.
The record of record is yours, not ours. Every access lands in your own CloudTrail — an
AssumeRole from our account, tagged with a per-scan session name — on infrastructure we cannot
touch. So you never have to take our audit log on faith: you can confirm exactly what we accessed from your
own side. We treat "here is everything we touched" as a feature, not a disclosure.
Read-only is the core promise. The risk of giving a third party write access to a production AWS account is never worth it, and it is unnecessary: every fix we find is a config or code change your team applies from a diff/PR. Advise and assist, never act.
Two ways. (1) The role's permissions are the proof — review the policy; it reads logs and metrics, nothing more. (2) Our access is in your CloudTrail and in the audit log we hand you. What crosses the boundary is hashes and counts; raw bodies are never persisted on our side. (See the body-handling note above for the precise design-partner vs GA distinction — we do not overstate it.)
Then you get a clean report confirming it — which is a legitimate outcome and the honest one. The scan is read-only and time-bounded; the worst case is a tidy confirmation that you're not leaking.
No. This is a free design-partner scan to validate the detectors on real workloads. There is no charge, no auto-conversion, and no obligation. The way in is the same canonical entry point used everywhere: "Apply for a free Bedrock cost-leak scan."
If the trust boundary works for your team, the way in is one qualification form. The scan is read-only and the findings are yours to keep, whether or not we work together.