8.1 IAM Least Privilege & Resource Policies for Bedrock

8.1 IAM Least Privilege & Resource Policies for Bedrock

This independent study guide by OpenExamPrep helps candidates prepare for the AWS Certified Generative AI Developer - Professional (AIP-C01) examination. Securing enterprise generative AI architectures requires rigorous application of the principle of least privilege across identity and access management (IAM). Foundation models, custom fine-tuned weights, knowledge base document repositories, and autonomous agent action groups represent high-value enterprise assets. A single overly permissive IAM wildcard (bedrock:* on *) can expose sensitive model configurations, incur massive financial charges via unmetered inference or provisioned throughput creation, and breach corporate compliance boundaries.

To construct production-grade security boundaries, developers must master the demarcation between control-plane and data-plane operations, the precise ARN formatting rules for AWS-managed versus customer-owned resources, the mechanics of service execution roles, and condition-based policy enforcement.

---

Control Plane vs. Data Plane IAM Architecture

Amazon Bedrock separates administrative lifecycle management from runtime model inference. IAM policies must align with these distinct operational tiers:

[!IMPORTANT] A common architectural requirement on the AIP-C01 exam is ensuring that application runtime identities have zero control-plane permissions. A microservice responsible for generating customer responses should only be granted bedrock:InvokeModel or bedrock:InvokeModelWithResponseStream on a specific model ARN, never broad actions like bedrock:* or administrative actions like bedrock:GetFoundationModel.

---

Granular Resource ARN Scoping

Unlike traditional AWS services where resources always reside within a specific AWS account, Amazon Bedrock hosts both AWS-managed foundation models and customer-managed artifacts. Scoping IAM policies requires understanding these ARN syntax nuances:

1. Foundation Model ARNs (AWS-Managed)

Foundation models provided by third-party model providers (Anthropic, Meta, Mistral, Cohere, AI21) and Amazon (Titan, Nova) are owned and managed by AWS. Consequently, their ARN contains an empty account field (two consecutive colons ::):

arn:aws:bedrock:{region}::foundation-model/{model-id}

Example: arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0 Example: arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0

[!WARNING] If an IAM policy specifies arn:aws:bedrock:us-east-1:123456789012:foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0, the policy will fail to authorize inference. Because the foundation model is AWS-managed, inserting an account ID creates an invalid ARN that does not match the service-evaluated identity.

2. Custom Model ARNs (Customer-Owned)

When a team fine-tunes a model or performs continued pre-training, the resulting customized model weights belong to the customer account. The ARN includes the 12-digit account ID and custom model identifier:

arn:aws:bedrock:{region}:{account-id}:custom-model/{model-name}/{custom-model-id}

3. Provisioned Model Throughput ARNs

Provisioned Throughput is a customer resource used for supported reserved-capacity needs, but it still requires quota, error, and latency monitoring:

arn:aws:bedrock:{region}:{account-id}:provisioned-model/{provisioned-model-id}

4. Knowledge Base & Agent ARNs

Managed RAG and autonomous agent resources are customer-scoped:

• Knowledge Base: arn:aws:bedrock:{region}:{account-id}:knowledge-base/{knowledge-base-id}
• Agent: arn:aws:bedrock:{region}:{account-id}:agent/{agent-id}
• Agent Alias: arn:aws:bedrock:{region}:{account-id}:agent-alias/{agent-id}/{agent-alias-id}
• Guardrail: arn:aws:bedrock:{region}:{account-id}:guardrail/{guardrail-id}

---

Production IAM Policy: Least-Privilege Inference with Guardrail Enforcement

In enterprise environments, developers often need to enforce mandatory safety guardrails alongside model invocations. IAM policies can use the bedrock:GuardrailIdentifier condition key, including a numbered guardrail version ARN, to require the approved guardrail on supported inference actions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowScopedModelInvocationWithGuardrail",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0",
        "arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0"
      ],
      "Condition": {
        "ArnEquals": {
          "bedrock:GuardrailIdentifier": "arn:aws:bedrock:us-east-1:123456789012:guardrail/a1b2c3d4e5f6"
        }
      }
    },
    {
      "Sid": "AllowApplyGuardrail",
      "Effect": "Allow",
      "Action": "bedrock:ApplyGuardrail",
      "Resource": "arn:aws:bedrock:us-east-1:123456789012:guardrail/a1b2c3d4e5f6"
    }
  ]
}

Under this policy, if an API client submits an InvokeModel request without supplying the required guardrail ID in the request headers or parameters, Bedrock evaluates the condition as unsatisfied and returns an AccessDeniedException.

---

Service Execution Roles & Trust Relationships

Amazon Bedrock features autonomous services—specifically Knowledge Bases and Agents—that act on your behalf to access other AWS services (Amazon S3, OpenSearch Serverless, AWS Lambda). These services require dedicated Service Execution Roles.

1. The Trust Policy (AssumeRole)

Both Knowledge Bases and Agents must establish a trust policy with the Amazon Bedrock service principal (bedrock.amazonaws.com):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockTrustPolicyWithConfusedDeputyProtection",
      "Effect": "Allow",
      "Principal": {
        "Service": "bedrock.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:bedrock:us-east-1:123456789012:knowledge-base/*"
        }
      }
    }
  ]
}

Mitigating the Confused Deputy Vulnerability

The confused deputy problem occurs when an entity that doesn't have permission to perform an action coerces a privileged service into performing it. To prevent another AWS account from using Bedrock to assume your execution role and exfiltrate data, you must always include the aws:SourceAccount and aws:SourceArn condition keys in the trust policy.

2. Knowledge Base Execution Role Permissions

A Knowledge Base execution role requires a permissions policy that grants access to:

• S3 Data Source: s3:GetObject and s3:ListBucket on the document repository bucket.
• Embedding Model: bedrock:InvokeModel on the embedding model ARN (e.g., amazon.titan-embed-text-v2:0).
• Vector Store: aoss:APIAccessAll for Amazon OpenSearch Serverless (or RDS permissions for Aurora pgvector).
• KMS Decryption: kms:Decrypt if data sources or vector stores are encrypted with Customer Managed Keys.

3. Bedrock Agent Execution Role Permissions

An Agent execution role requires permissions to:

• Invoke Foundation Model: bedrock:InvokeModel on the LLM that powers the agent's ReAct reasoning loop.
• Execute Action Groups: the target Lambda function needs a resource-based policy that permits the bedrock.amazonaws.com service principal to invoke it, restricted by source account and agent ARN as appropriate.
• Query Knowledge Bases: bedrock:Retrieve scoped to the attached knowledge base ARNs.

---

Attribute-Based Access Control (ABAC) with Tags

In large enterprises with multiple development teams sharing an AWS account, managing individual IAM policies for every developer or model leads to policy explosion and operational friction. Attribute-Based Access Control (ABAC) solves this by granting permissions based on matching tags.

Tagging Bedrock Resources

Tags can be attached to custom models, provisioned throughput, knowledge bases, guardrails, and agents (e.g., Environment = Production or Department = Finance).

ABAC Policy Example

The following policy allows developers to invoke foundation models or custom models only if the resource's Environment tag matches the developer's IAM principal tag:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DynamicABACInvocation",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:us-east-1:123456789012:custom-model/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"
        }
      }
    }
  ]
}

When a developer tagged with Environment = Development attempts to invoke a custom model tagged with Environment = Production, Bedrock denies the request automatically without requiring manual policy edits.

---

Common Exam Traps & High-Stakes Scenarios

• Trap: Specifying an Account ID in Foundation Model ARNs. AWS-managed foundation models have no account ID. Writing arn:aws:bedrock:us-east-1:123456789012:foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0 will result in access denied. Always remember the empty double colon (::foundation-model/).
• Trap: Conflating bedrock:Retrieve and bedrock:RetrieveAndGenerate. The bedrock:Retrieve action queries the knowledge base and returns raw document chunks and relevance scores. The bedrock:RetrieveAndGenerate action queries the knowledge base and passes the chunks to a foundation model to synthesize a completed response. An application that sends a prompt directly to a model needs the applicable inference action, such as bedrock:InvokeModel or bedrock:InvokeModelWithResponseStream. bedrock:Retrieve is for Knowledge Base retrieval and does not invoke a foundation model by itself.
• Trap: Putting action-group invocation permission in the wrong policy. The action Lambda needs a resource-based lambda:InvokeFunction permission for the bedrock.amazonaws.com service principal. Restrict it with the relevant source account and agent ARN; changing only the Lambda execution role does not authorize the service invocation.
• Trap: Omitting Confused Deputy Protection. Questions regarding security audits or SOC2 compliance will flag Bedrock trust policies that lack aws:SourceAccount and aws:SourceArn.