A historic type-foundry assumes that because they picked Amazon Bedrock, AWS is responsible for their prompt logs, their IAM, and which volunteers can invoke. What is the accurate split?

The historic type-foundry assumes that picking Amazon Bedrock moves responsibility for prompt logs, IAM, and who can invoke entirely to AWS. Under shared responsibility, AWS secures the underlying cloud and managed service infrastructure. The foundry still owns identities, data classification, configuration, prompt content handling, and access decisions for volunteers.

Claiming Bedrock moves prompt logs, IAM, and invoke rights entirely to AWS fails because those are classic customer-side duties in a managed foundation-model API. Claiming the foundry patches the hypervisor while AWS writes the volunteer roster reverses the split: AWS handles the undifferentiated infrastructure; the customer manages who may call the API. Claiming shared responsibility does not apply to foundation-model APIs fails because managed generative services still follow the shared model.

Exam caveat: "managed" reduces operational burden on servers and scaling; it does not erase customer accountability for misuse, over-privilege, or sensitive prompts stored in logs the customer controls. Operational check: document the split in the foundry's AI security plan—AWS for service infrastructure; foundry for IAM roles, invoke allow-lists, encryption choices, and retention of prompt/response logs—and review that plan when onboarding new volunteer invoke roles.