Beyond "Allow" and "Deny"

In the previous lesson, we learned about basic IAM roles. However, a Professional Developer needs more precision. You don't just want to say "The Lambda can call Bedrock." You want to say:

"The Lambda can call Bedrock ONLY if the request comes from our corporate VPC."
"The user can call the model ONLY during business hours."
"The Agent can only use models that have been tagged as 'Approved-for-Production'."

In this lesson, we will master IAM Condition Keys and Attribute-Based Access Control (ABAC) for GenAI workloads.

1. What are IAM Condition Keys?

The Condition block in an IAM policy allows you to add logic to your permissions.

Common AI Condition Keys:

aws:SourceVpc: Restrict access to a specific Virtual Private Cloud.
aws:PrincipalTag: Restrict access based on the tags of the user/role.
bedrock:ModelId: (Generic key) Specifically restricts which foundation model can be invoked.

2. Using SourceVpc to Secure AI Pipelines

A common requirement for the AIP-C01 exam is ensuring that your AI calls never touch the public internet. By using an Interface VPC Endpoint, your traffic stays private. To enforce this, you write an IAM policy that Denies any request that does not originate from that VPC.

{
    "Effect": "Deny",
    "Action": "bedrock:InvokeModel",
    "Resource": "*",
    "Condition": {
        "StringNotEquals": {
            "aws:SourceVpc": "vpc-05fd9EXAMPLE"
        }
    }
}

This "Deny-by-Default" approach ensures that even if a developer leaks their credentials, they cannot be used from a home Wi-Fi or a hacker's laptop.

3. ABAC: Attribute-Based Access Control

Instead of listing every Resource ARN in your policy (which gets messy), you can use Tags.

Scenario: You have 100 RAG knowledge bases. Some are for "Project Alpha" and some for "Project Beta." Requirement: Developers on Team Alpha should only see Alpha KBs. Implementation:

Tag your KBs with Project: Alpha.
Tag your developers with Team: Alpha.
Use a single IAM policy that allows access StringEquals: { bedrock:ResourceTag/Project: "${aws:PrincipalTag/Team}" }.

graph LR
    User[User: Team=Alpha] -->|Request| KB[Knowledge Base: Project=Alpha]
    KB -->|Match!| Access[Allowed]
    
    User2[User: Team=Beta] -->|Request| KB
    KB -->|No Match| Deny[Denied]

4. Service Control Policies (SCPs)

If you are an architect for an entire organization, you use SCPs (part of AWS Organizations) to set "Guardrails" for all AWS accounts.

Example SCP: "Disable the ability for any account in the organization to use Amazon Bedrock in any region except us-east-1 and eu-central-1."

5. Protecting the Model Creation Lifecycle

It's not just about "Invoking" models. You must also protect the Configuration.

bedrock:CreateProvisionedThroughput: Expensive action. Should be restricted to senior architects.
bedrock:UpdateKnowledgeBase: Critical action. Incorrect chunking settings here could break the whole app.

6. Pro-Tip: The "MFA" Condition

For highly sensitive AI models (e.g., those processing financial algorithms), you can require Multi-Factor Authentication (MFA) at the API level.

"Condition": {
    "Bool": {
        "aws:MultiFactorAuthPresent": "true"
    }
}

This means the Boto3 script will fail unless the user has authenticated with their MFA device within the last X minutes.

Knowledge Check: Test Your Fine-Grained Logic

?Knowledge Check

An enterprise requires that their internal AI models only be accessible from their corporate network. Which IAM condition key should be added to the model invocation policy to enforce this restriction?

Summary

Generic permissions are dangerous. By using Conditions and ABAC, you create a "Dynamic Shield" that adapts to the context of the request. In the final lesson of Module 9, we look at Resource Isolation—ensuring different teams and applications can coexist safely in the same AWS account.

Next Lesson: Dividing the Kingdom: Resource Isolation and Multi-tenancy

Precision Security: Fine-grained Policies and Condition Keys