5.2.1. Network Isolation and Access Control

💡 First Principle: Network isolation for GenAI applications means building a perimeter where FM API traffic, vector store queries, and document storage access all flow through private AWS network paths — no public internet traversal, even for encrypted traffic.

VPC endpoint architecture for Bedrock:

IAM least-privilege for FM invocations — the exam-critical patterns:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel"],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["bedrock-agent-runtime:Retrieve"],
      "Resource": [
        "arn:aws:bedrock:us-east-1:123456789:knowledge-base/KBID12345"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::my-kb-documents/*"],
      "Condition": {
        "StringEquals": {"s3:ExistingObjectTag/classification": "internal"}
      }
    }
  ]
}

AWS Lake Formation for fine-grained data access in RAG pipelines: When your FM application queries structured data (Glue Data Catalog tables, Athena queries), Lake Formation enforces column-level and row-level access controls — preventing an FM application from accessing data columns it has no business reason to read:

# Lake Formation column-level security example
# The FM application's role can only see name, department, hire_date
# SSN, salary, and performance_rating are invisible to this role
# Athena query on the same table returns different columns per role
query = "SELECT * FROM employee_directory WHERE department = 'Engineering'"
# Role with Lake Formation column filter: returns only name, department, hire_date
# Role without filter: returns all columns including SSN, salary

⚠️ Exam Trap: VPC endpoints for Bedrock prevent traffic from leaving the AWS network, but do not prevent lateral movement within the VPC. A compromised Lambda function with overly broad IAM permissions could still access other VPC resources. Least-privilege IAM policies are required independently of network isolation — the two controls operate at different layers.

Access control for agents: AgentCore Identity and Policy

An agent is a new kind of principal: it acts for a user, calls tools the user never sees, and can be steered by text it reads. Two AgentCore services give it the same least-privilege treatment as the IAM patterns earlier in this section.

AgentCore Identity manages who the agent is and which credentials it may use:

• Each agent gets a workload identity in a central agent identity directory.
• Inbound: a JWT authorizer validates callers against your identity provider (Amazon Cognito, Okta, Microsoft Entra ID, Auth0), or callers use IAM SigV4.
• Outbound: OAuth 2.0 and API key credential providers reach third-party services. The client credentials grant (2LO) is machine-to-machine; the authorization code grant (3LO) gets the user's consent to act on their data.
• Tokens and keys live in the token vault, encrypted with AWS KMS and released only to a verified agent identity. The @requires_access_token and @requires_api_key decorators inject them, so no secret appears in code.

Policy in AgentCore decides what the agent may do with a tool:

• A policy engine is associated with an AgentCore Gateway and intercepts every tool call before it runs, at a boundary outside the agent's code.
• Rules are written in Cedar (or in plain English, which is converted to Cedar, validated against a schema generated from the gateway's tools, and checked with automated reasoning for rules that are overly permissive, overly restrictive, or unsatisfiable).
• The engine applies default-deny and forbid-wins semantics. Conditions can use the principal (an OAuth user built from the JWT, with claims such as role, or an IAM caller) and the tool's input parameters.
• Temporal policies, written in Dogwood (compatible with Cedar), look at earlier events in the same policy session, for example to require an approval before a transfer or to cap how many times an action runs.
• Every decision is logged to CloudWatch for audit.

forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RefundAPI___issue_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/support"
)
when {
  context.input has amount && context.input.amount > 500
}
unless {
  principal.hasTag("role") && principal.getTag("role") == "manager"
};

Because the engine is default-deny, a separate permit policy must allow issue_refund in the first place; this forbid then carves out the large refunds, and forbid wins over any permit. Tool actions are named <target>___<tool> from the schema the engine generates for the gateway, and an agent's tools/list response includes only the tools it is authorized to use.

⚠️ Exam Trap: "The control must hold even if the agent is manipulated by a prompt injection" rules out system-prompt instructions, self-check tools, and Guardrails denied topics. Only a check outside the model, such as a gateway Policy rule, meets it. Guardrails still belong in the design for content safety, and a Dogwood policy can consult a guardrail's score as one input.

Encryption keys you control: when auditors need keys you own, rotate and can disable, use a customer managed KMS key. Apply it to the OpenSearch Serverless collection's encryption policy, the S3 document and log buckets (SSE-KMS), and the knowledge base. AWS managed keys also encrypt at rest, but you cannot control their key policy or rotation.

What Bedrock does with your data: Amazon Bedrock doesn't use your prompts and completions to train any models, and it doesn't share them with model providers. Inference runs in AWS-owned model deployment accounts that providers cannot access. By default Bedrock keeps no copy of inputs or outputs; the exceptions are logs you turn on (invocation logging) and, for a few models, retention of up to 30 days for abuse detection, which AWS stores without sharing it. A VPC endpoint keeps the traffic on the AWS network, but processing still happens in that AWS-managed infrastructure, outside your VPC.

Making the private path mandatory: a VPC endpoint is optional until a policy requires it. Add a Deny unless aws:SourceVpce equals your endpoint ID to the caller's identity policy (or an SCP). Give the subnet no route to an internet or NAT gateway. A call that bypasses the endpoint is then refused instead of silently taking the public path.

Credentials and secrets: replace long-lived IAM access keys on laptops with temporary credentials from IAM Identity Center (SSO). A static key never expires on its own. Keep API keys and other secrets in AWS Secrets Manager rather than Lambda environment variables, which anyone allowed to call lambda:GetFunctionConfiguration can read.

Reflection Question: Your GenAI application processes employee HR queries. The Lambda function has an IAM role with bedrock:* and s3:* permissions for "simplicity." A security audit flags this. Describe the minimum IAM permissions the Lambda role should have, and what AWS service provides fine-grained access control at the data column level?