bedrock has no access enabled for model %q (%s): %w model

Error message

bedrock has no access enabled for model %q (%s): %w
  model access is granted per account and per region in the Bedrock console; an IAM policy alone does not enable it

What it means

explainError (internal/llm/client.go:1112) matches Bedrock's 'don't have access to the model' wording, which the service sends when the AWS account has not enabled model access for that model. The rewrite makes clear this is an account/region-level console setting, NOT something an IAM policy can fix — a common misdiagnosis.

Source

Thrown at internal/llm/client.go:1112

	msg := err.Error()
	where := c.bedrockWhere()

	// Order matters here, and the two AccessDenied shapes are why: Bedrock
	// answers both "your IAM policy forbids this" and "this account has not
	// enabled the model" with AccessDeniedException, and the fixes have nothing
	// in common. The specific wording is matched before the generic code.
	switch {
	// First: the bearer-token path produces this even when credentials are
	// otherwise valid, so a later "denied" branch would mislabel it.
	case strings.Contains(msg, "Invalid API Key format"):
		if os.Getenv("AWS_BEARER_TOKEN_BEDROCK") != "" {
			return fmt.Errorf("bedrock rejected the token in AWS_BEARER_TOKEN_BEDROCK (%s): %w\n"+
				"  unset that variable to sign requests with SigV4 instead", where, err)
		}
		return fmt.Errorf("bedrock rejected an API-key header rather than a signature (%s): %w\n"+
			"  no api_key applies to bedrock; this means a bearer token reached the request, not that a key is missing", where, err)
	case strings.Contains(msg, "don't have access to the model"):
		return fmt.Errorf("bedrock has no access enabled for model %q (%s): %w\n"+
			"  model access is granted per account and per region in the Bedrock console; an IAM policy alone does not enable it", model, where, err)
	case strings.Contains(msg, "model identifier is invalid"),
		strings.Contains(msg, "inference profile") && strings.Contains(msg, "not found"):
		return fmt.Errorf("bedrock rejected model %q (%s): %w\n"+
			"  run `aws bedrock list-inference-profiles%s` to see what this account offers — IDs are account- and region-scoped, and a version suffix such as -v1:0 is invalid for the newer families",
			model, where, err, listProfilesRegionArg(c.awsRegion))
	// Specific credential codes only. A bare "expired" would also claim an
	// expired TLS certificate is an SSO problem.
	case strings.Contains(msg, "ExpiredToken"), strings.Contains(msg, "ExpiredTokenException"),
		strings.Contains(msg, "SSOProviderInvalidToken"), strings.Contains(msg, "InvalidGrantException"),
		strings.Contains(msg, "NoCredentialProviders"), strings.Contains(msg, "failed to refresh cached credentials"):
		return fmt.Errorf("bedrock could not authenticate: AWS credentials are expired or unavailable (%s): %w\n"+
			"  run `aws sso login%s`, or refresh whichever credential source this profile uses", where, err, ssoLoginProfileArg(c.awsProfile))
	// "not authorized to invoke this API operation" is IAM's own wording, so it
	// belongs here rather than in the model-access branch above: the fix is a
	// policy change, not a console toggle.
	case strings.Contains(msg, "AccessDenied"),
		strings.Contains(msg, "not authorized to invoke this API operation"):

View on GitHub (pinned to 5cf97d0d15)

Solutions

Open the AWS Bedrock console → Model access, select the region, and request/enable access for the model
Wait for the access grant to complete (usually minutes; some models longer)
Re-run after confirmation — check with `aws bedrock list-foundation-models --region <region>` that the model is offered and enabled
If using a cross-account role, enable model access in the account that actually owns the credentials

Example fix

// before
aws bedrock invoke-model --model-id anthropic.claude-sonnet-4-20250514 ...  # AccessDenied: don't have access
// after
# Console: Bedrock → Model access → Claude Sonnet 4 → Request/Enable
aws bedrock invoke-model --model-id anthropic.claude-sonnet-4-20250514 ...  # succeeds

Defensive patterns

Strategy: fallback

Validate before calling

out, err := exec.Command("aws", "bedrock", "list-foundation-models",
    "--region", region,
    "--by-provider", "anthropic").Output()
if err != nil || len(out) == 0 {
    return errors.New("model access not enabled for Anthropic models in this region — enable in the Bedrock console")
}

Try / catch

_, err := cl.Call(ctx, messages)
if err != nil && strings.Contains(err.Error(), "no access enabled for model") {
    return fmt.Errorf("enable the model in Bedrock console → Model access for %s, then retry: %w", region, err)
}

Prevention

Enable model access in the Bedrock console for every region you deploy in
Re-check access after creating a new AWS account or switching regions
Use `aws bedrock list-foundation-models` in CI preflight
Remember IAM policies cannot substitute for console model-access grants

When it happens

Trigger: Invoking a Bedrock model (e.g. anthropic.claude-*) in a region where the account never subscribed/enabled that model; service returns the access-denied wording and this branch fires.

Common situations: New AWS account that has not requested Claude access; using a model available in us-east-1 from a freshly-used ap-northeast-1 account where access was never granted; org switched regions without re-enabling models.

Related errors

AI-assisted analysis of alibaba/open-code-review@5cf97d0d15 (2026-09-02). Data as JSON: /api/errors/72d030322fade96f. Report an issue: GitHub.