From the AWS edition of November 9, 2026
AWS's Bedrock FedRAMP and DoD IL4/IL5 model status page, updated November 9, lists Anthropic models through Fable 5.1 but not Fable 5.2 or Mythos 5.2
Amazon Web Services · Cross-SLED compliance / government cloud authorization · United States (commercial US East/West and GovCloud (US))
- Publisher
- AWS Compliance
- Original publication
- 2026-11-09
- Source retrieved
- 2026-11-10
- Event date
- 2026-11-09
What happened
AWS's model-level authorization page for Bedrock shows 'Last updated: November 9, 2026' and a table of model families against U.S. East/West (FedRAMP Class C), GovCloud (FedRAMP Class D) and DoD IL4/IL5 columns. At retrieval, the Anthropic rows ran from Claude 3 Haiku through 'Fable 5.1'; neither Fable 5.2 nor Mythos 5.2 appeared on the page, even though both were announced for GovCloud the same day. The AWS GovCloud Bedrock user guide (also opened) points customers to this page for FedRAMP Class D and IL approvals.
Why it matters
For state agencies and universities that require FedRAMP or StateRAMP-aligned authorization per model, GovCloud availability is not the same as an authorization listing. Compliance teams should check this page before approving the newly available models.
Evidence and measured results
Vendor compliance documentation observed at a point in time. The absence of a listing was checked by text search of the retrieved page; it does not prove the models will not be authorized later.
Limitations and uncertainty
Point-in-time observation of a page that may be updated soon; the text extraction did not let us map each 'X' to a specific column, so no claim is made about Fable 5.1's exact authorization levels.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-10; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Agencies may read GovCloud model availability as equivalent to FedRAMP/IL authorization.
- Stakeholders
- Compliance officer / ATO authorizer
- Agency CIO
- Cloud governance lead
- Discovery questions
- Which authorization level does each AI workload require?
- Does policy require per-model authorization listing?
- Who monitors the listing for changes?
- Value hypothesis
- A model-level allow-list tied to the authorization page reduces compliance risk when new models launch.
- Potential engagement
- Model-authorization guardrail setup for Bedrock accounts.
- Unsupported claims
- Any authorization status for Fable 5.2 or Mythos 5.2
- Timing of future listings
Pre-sales engineering
Role takeaway
- Fit
- Strong fit as a governance control for regulated Bedrock workloads.
- Architecture and integration
- IAM/SCP restrictions on Bedrock model IDs aligned to the authorization listing.
- Prerequisites
- Per-workload authorization requirement
- Owner for listing updates
- SCP/IAM policy management
- Constraints
- Listing may lag announcements
- Column mapping must be read on the live page
- Security
- Prevents regulated data from reaching models outside the authorization boundary.
- Proof of value
- Automated comparison of allowed model IDs with the listing
- Test that an unlisted model call is denied in regulated accounts
Delivery
Role takeaway
- Work
- Add a model-authorization checkpoint to AI intake and enforce it in policy.
- Dependencies
- Compliance interpretation
- Maintained allow-list
- Ownership
- Cloud governance / compliance function.
- Skills and adoption
- Platform teams need to read authorization tables and maintain policy-as-code.
- Governance checkpoints
- Listing re-check on each model request
- Authorization level recorded in ATO
- Acceptance criteria
- Proposed: no unlisted model reachable from regulated accounts
- Proposed: allow-list reviewed within a set period after page updates
- Risks
- Adopting models before listing
- Misreading table columns
- Page changes without notice
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Authorization is tracked per model, not per service, so platform teams need model-level allow-lists in Bedrock (for example via IAM or service control policies).
Governance
Who approves, reviews and stays accountable for outcomes?
Supports a governance rule: only models listed for the required authorization level may process regulated data. The page may lag announcements.
Security and privacy
What data, permissions and controls need testing?
Using an unlisted model for regulated data could fall outside an agency's authorization boundary.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Not addressed.
Procurement
What should contracts, pricing and exit terms secure?
Procurement and ATO packages should reference this model-level page rather than the GovCloud availability announcement.
Operating model
Which teams own the service once it runs?
Requires a routine check of the listing when new models are announced.
Publication history
- 2026-11-09AWS · Issue 118 resources
Stable resource ID: aws-bedrock-models-fedramp-il-status-no-5-2-listing-20261109