Research what it takes to scan Amazon Bedrock, and record it as a Later item

[kiwifellows]

EOF2

What and why

Research only. This does not add Bedrock scanning — it establishes what securing a Bedrock environment involves, what TOPS would have to do to check it, and what would have to be true before it is worth doing. Recorded so the decision is made once and the research is not redone.

New: docs/features/bedrock-scanning.md. Roadmap gains a Later row with a named trigger, plus a section summarising the finding.

User story

Not a feature. Documentation for a prospective scanner-coverage item, filed under Later — real, but waiting on a trigger.

What is in the doc

• The framing that decides the scope. "Bedrock security" is two problems: a config plane a CSPM can see (logging off, no guardrail, unencrypted custom models, over-scoped agent roles) and an inference plane it cannot (prompt injection, jailbreaks, exfiltration through completions). The published research — Unit 42's "Agent God Mode", Sonrai on AgentCore — is all about the second, but the enabling conditions are nearly all in the first, and Bedrock ships with those off by default. Stated explicitly so nothing we ship implies we detect prompt injection.
• The controls worth checking, in three tiers with the API call, response field and a severity argument for each. Tier 2 (CMK encryption) is deliberately capped at low/medium — the data is encrypted either way, and overstating it is how a scanner trains people to ignore it.
• Comparator analysis. Prowler ships 13 Bedrock checks off just five API calls, and they map almost one-to-one onto Tier 1 and 2. The convergence is the reassuring part: this is not an open-ended research problem.
• There is no CIS benchmark for Bedrock, so rules would go in basic.json, not cis.json. Recorded so nobody invents control numbers.
• Sizing in four slices, and a note that A+B without C is the one combination that makes the product worse.

The finding that outlives the Bedrock question

Model invocation logging is the highest-value check and is account-level on a regional service — a combination TOPS has not had (IAM's getAccountPasswordPolicy is account-level but global).

ScanResult::identityHash() does not include region, and createFinding() falls back to 'unknown' for id-less tasks. So the same check across ~17 regions produces one identity hash, one row under the unique index, and with five concurrent region workers since PERF-6, the last region to finish wins — a finding that appears and disappears between scans with nothing changing.

This is a latent property of D-11's identity key, not a Bedrock quirk; Bedrock is just the first service that would hit it. Worth recording as a known limitation of D-11 whether or not Bedrock is ever scanned, so the next regional account-level check does not rediscover it in production. Flagged in the doc and the roadmap; not filed as an issue, since that is a call for the maintainer.

How it was tested

Documentation only — no code paths changed, so no tests were added or run. Claims were verified against the repo and the SDK rather than from memory:

• Every operation resolves: each call the design needs was run through GenericAwsScanner::supportsOperation() against the installed SDK (3.369.9), which ships all eight Bedrock clients. All pass, so no custom scanner is needed.
• Response shapes read out of the bundled API models, not from documentation — including that Bedrock uses lowerCamelCase members, unlike every existing rule. Flagged as a footgun precisely because a wrong key yields no finding and no error, which scan:validate-rules cannot catch.
• IAM coverage: ReadOnlyAccess confirmed to grant each of the 11 required bedrock: actions individually.
• The collision: verified at ScanResult.php:98 and FindingsEngine.php:244.
• The ~17 regions figure is derived from the roadmap's own ~153 region jobs and the 9-of-11 services that are regional: true, not guessed.
• Not asserted: an exact count of bedrock: actions in ReadOnlyAccess. Two reads of the AWS reference page disagreed (54 vs 51), so the doc quotes no figure and rests on the per-action confirmations instead. Noted in the doc.

---

Quality gate

• Acceptance criteria are met — the ask was to research and record, not to build
• Solves the user problem simply — a doc and a roadmap row; no code, no speculative abstraction
• Follows the practices in docs/practices/
• Tests written and passing — none. Documentation-only change; tests would ship with the rules
• Documentation updated — this PR is the documentation
• No obvious performance issues — n/a
• Ready for production — n/a, nothing ships

Practices check

• Simplicity — the recommendation is explicitly not now, and names what would have to be true first. The first-ship shape is chosen for needing no engine change
• Security — no secrets. Describes control gaps in a service TOPS does not yet scan; no attack recipe
• Product — applies the decision framework directly, and records that the item fails "what are we willing to remove to add this?"

Multi-tenancy, Database, Testing and Scan definitions are untouched.

Out of scope

• Any Bedrock rules or tasks.json. Nothing is added to app/rules/.
• Bedrock IAM role analysis — the highest-value control in the research and the hardest, since it means evaluating policy documents rather than reading a boolean. Arguably not a Bedrock feature at all; sized separately as L.
• AgentCore, where the most alarming published research sits. Newest and least stable surface; revisit once the base service is proven.
• Fixing the identity-hash collision. Named, not fixed.

🤖 Generated with Claude Code