Severity: Pilot-blocking
Add-in host: Excel (eu-central-1)
What's wrong
The add-in attempts to invoke claude-opus-4-7 during the sign-in/connection probe, regardless of which models are permitted in the account's IAM policy. If claude-opus-4-7 is not explicitly allowed in the IAM role attached to the Bedrock integration — for example, because an admin has deliberately excluded it for cost control reasons — the probe returns a 403 and sign-in fails entirely, blocking all users.
This makes it impossible to use standard IAM resource-level permissions to control which Claude models are accessible without breaking the add-in at sign-in.
Steps to reproduce
- Configure the Claude for Microsoft 365 add-in with Bedrock direct, region
us-east-1
- Attach an IAM policy that grants
bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on Sonnet model ARNs only — deliberately excluding Opus 4.7 for cost reasons
- Attempt to sign in to the add-in
- Sign-in fails with 403
Expected behaviour
The add-in should discover which models are available and permitted in the configured account and region, and use one of those for its connection probe and default model selection. It should not assume a specific hardcoded model ID is accessible.
Actual behaviour
The add-in hardcodes claude-opus-4-7 as the model for its sign-in probe. If that model is not permitted in the IAM policy, sign-in returns 403 regardless of what other models are available.
Suggested fix
Bedrock exposes ListInferenceProfiles with a typeEquals=SYSTEM_DEFINED filter, which returns the exact invokeable profile IDs for the account and region. The add-in could call this at sign-in time, filter to Anthropic models, and use the results to populate its model selection rather than assuming a hardcoded ID is permitted. It would naturally respect whatever the IAM policy allows — meaning admins can restrict to Sonnet-only simply by granting access to Sonnet, with no additional workarounds needed.
The IAM role would need bedrock:ListInferenceProfiles added alongside the existing bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream permissions — a minimal addition.
Related
Related to #217 — the root cause is the same: the add-in hardcodes model IDs rather than discovering what is available and permitted in the configured account and region.
Severity: Pilot-blocking
Add-in host: Excel (eu-central-1)
What's wrong
The add-in attempts to invoke
claude-opus-4-7during the sign-in/connection probe, regardless of which models are permitted in the account's IAM policy. Ifclaude-opus-4-7is not explicitly allowed in the IAM role attached to the Bedrock integration — for example, because an admin has deliberately excluded it for cost control reasons — the probe returns a 403 and sign-in fails entirely, blocking all users.This makes it impossible to use standard IAM resource-level permissions to control which Claude models are accessible without breaking the add-in at sign-in.
Steps to reproduce
us-east-1bedrock:InvokeModelandbedrock:InvokeModelWithResponseStreamon Sonnet model ARNs only — deliberately excluding Opus 4.7 for cost reasonsExpected behaviour
The add-in should discover which models are available and permitted in the configured account and region, and use one of those for its connection probe and default model selection. It should not assume a specific hardcoded model ID is accessible.
Actual behaviour
The add-in hardcodes
claude-opus-4-7as the model for its sign-in probe. If that model is not permitted in the IAM policy, sign-in returns 403 regardless of what other models are available.Suggested fix
Bedrock exposes
ListInferenceProfileswith atypeEquals=SYSTEM_DEFINEDfilter, which returns the exact invokeable profile IDs for the account and region. The add-in could call this at sign-in time, filter to Anthropic models, and use the results to populate its model selection rather than assuming a hardcoded ID is permitted. It would naturally respect whatever the IAM policy allows — meaning admins can restrict to Sonnet-only simply by granting access to Sonnet, with no additional workarounds needed.The IAM role would need
bedrock:ListInferenceProfilesadded alongside the existingbedrock:InvokeModelandbedrock:InvokeModelWithResponseStreampermissions — a minimal addition.Related
Related to #217 — the root cause is the same: the add-in hardcodes model IDs rather than discovering what is available and permitted in the configured account and region.