6.3 Generative AI Security: Amazon Bedrock Guardrails & Model Protection

6.3 Generative AI Security: Amazon Bedrock Guardrails & Model Protection

The rapid adoption of Large Language Models (LLMs) and Generative AI introduces an entirely new threat landscape to enterprise cloud architectures. Traditional perimeter security, network firewalls, and operating system hardening cannot detect application-layer generative AI threats such as prompt injection, jailbreaking, sensitive data leakage, and hallucinatory output execution. Securing generative AI workloads requires specialized architectural controls tailored to foundation model APIs, data retrieval pipelines, and autonomous agent frameworks.

Amazon Bedrock is a fully managed service that provides access to leading high-performing foundation models (FMs) from AI companies (including Anthropic, Meta, Mistral, Cohere, and Amazon) via a unified API, along with built-in enterprise security, privacy, and responsible AI guardrails.

---

The Shared Responsibility Model for Generative AI

Security in Amazon Bedrock operates under an extended AWS Shared Responsibility Model tailored for generative AI:

Loading diagram...

AWS Data Privacy & Isolation Guarantees

A common security objection when integrating third-party foundation models is whether customer proprietary data, internal intellectual property, or confidential customer queries will be absorbed into public model training datasets. In Amazon Bedrock:

• No Model Training on Customer Data: AWS contracts and technical architectures guarantee that customer prompts and model completions are never used to train base foundation models, nor are they shared with third-party model providers (e.g., Anthropic, Meta).
• No Prompt Storage by Default: Amazon Bedrock doesn't store or log your prompts and completions unless you enable model invocation logging, and model providers have no access to the Bedrock deployment accounts that run their models.
• Custom Models & Fine-Tuning: Fine-tuned model weights and customized embeddings are stored exclusively within the customer's dedicated AWS account and are encrypted at rest using the customer's AWS KMS keys.

---

OWASP Top 10 for Large Language Model (LLM) Applications

The Open Worldwide Application Security Project (OWASP) maintains a dedicated framework identifying the top security vulnerabilities in LLM applications; the table follows its 2025 edition. Mastering these vectors and their corresponding AWS countermeasures is essential for the SCS-C03 exam:

---

Amazon Bedrock Guardrails: Defense-in-Depth Architecture

Amazon Bedrock Guardrails provides an automated, programmable governance layer that evaluates both user inputs (prompts) and model completions against organizational policies. Crucially, Guardrails operates independently of the underlying foundation model: the same guardrail policy can be applied uniformly across Anthropic Claude, Meta Llama, Amazon Titan, and even external custom models via the ApplyGuardrail API.

Loading diagram...

1. Content Filters (Prompt Attack & Harmful Content)

Content filters evaluate text against six harmful categories: Hate, Insults, Sexual, Violence, Misconduct, and Prompt Attack:

• Prompt Attack Filter: Specifically detects and blocks prompt injection and jailbreak attempts (e.g., "Do Anything Now" [DAN] attacks, virtual persona hijacking, base64-encoded instruction overrides). Filters can be configured to filter strengths: NONE, LOW, MEDIUM, or HIGH.
• You can set separate strengths for inputs and outputs for the harmful-content categories; the Prompt Attack filter evaluates inputs only (tag untrusted user input so trusted system prompts are not flagged).

2. Denied Topics

Organizations can define custom out-of-scope conversation topics using natural language descriptions and optional sample phrases (few-shot learning). For example, a financial enterprise can configure a denied topic for Investment Advice:

• Topic Definition: "Providing specific recommendations or predictions regarding purchasing, selling, or holding stocks, cryptocurrency, or commodities."
• Sample Phrases: "Should I buy Tesla stock today?", "What crypto will double this week?"
• If a user prompt or model response strays into this topic, Guardrails intercepts the execution and returns a preconfigured response message.

3. Word Filters & Custom Blocklists

• Profanity Filter: Flags and blocks universally recognized offensive language.
• Custom Word Filters: Ingests lists of proprietary terms, competitor names, or regex patterns that must never appear in customer-facing prompts or completions.

4. Sensitive Information Filters (PII Redaction & Blocking)

Data leakage is a primary compliance concern under GDPR, HIPAA, and PCI DSS. Sensitive Information Filters identify Personally Identifiable Information (PII) using built-in detectors (e.g., Social Security Numbers, Credit Card Numbers, Email Addresses, Phone Numbers, AWS Access Keys) and custom regex:

• Action: Block: Halts generation immediately and returns an administrative error message if sensitive data is detected.
• Action: Mask: Dynamically replaces the sensitive token with a standardized placeholder tag (e.g., replacing 123-45-6789 with [SSN] or user@example.com with [EMAIL]). Masking can be applied to inputs (preventing PII from reaching the model) or outputs (preventing the model from returning PII to the end user).

5. Contextual Grounding Checks (Hallucination Mitigation)

In Retrieval Augmented Generation (RAG) architectures, foundation models occasionally produce hallucinations—statements that sound authoritative but have no factual basis in the retrieved enterprise reference documents. Contextual Grounding evaluates model responses against reference source chunks using two independent mathematical scores (0.0 to 1.0):

• Grounding Score: Measures whether every claim in the model's completion is factually supported by the retrieved reference chunks. If the score falls below the configured threshold, the response is blocked.
• Relevance Score: Measures whether the response directly addresses the user's original query. This prevents the model from generating unrelated filler content.

---

Model Invocation Logging & Audit Governance

Enterprise security compliance mandates a complete, tamper-resistant audit trail of all interactions with foundation models. Amazon Bedrock Model Invocation Logging captures complete telemetry across all model interactions.

Logging Architecture & Destinations

When enabled, invocation logging records:

• Timestamp, AWS Account ID, Region, and caller IAM Principal ARN.
• Model ID and Model ARN invoked.
• Input prompt text, token counts, and input image/document metadata.
• Output completion text, token counts, and latency.
• Detailed Guardrail intervention metadata (which filters triggered, confidence levels, redacted text).

Logging destinations can be configured independently or in tandem:

1. Amazon CloudWatch Logs: Optimized for real-time monitoring, metric filter alarms, and immediate EventBridge alerting when guardrail violations or suspicious prompt injections occur.
2. Amazon S3: Mandatory for large invocation payloads (e.g., multi-modal image inputs or responses exceeding CloudWatch log event limits) and long-term compliance archival. S3 lifecycle policies can transition audit logs to S3 Glacier Flexible Archive or Glacier Deep Archive.

Security & KMS Encryption Requirements

• S3 destination: A bucket policy lets the bedrock.amazonaws.com service principal call s3:PutObject on the log prefix, scoped with aws:SourceAccount and aws:SourceArn (the console can attach it for you). If the bucket uses SSE-KMS with a customer managed key, that key's policy must allow bedrock.amazonaws.com to call kms:GenerateDataKey. A customer managed key is your choice for control and audit, not a requirement of the feature.
• CloudWatch Logs destination: Bedrock assumes an IAM role that you create (trusting bedrock.amazonaws.com) with logs:CreateLogStream and logs:PutLogEvents on the log group; payloads too large for a log event can be delivered to S3.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AmazonBedrockLogsWrite",
      "Effect": "Allow",
      "Principal": { "Service": "bedrock.amazonaws.com" },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::enterprise-bedrock-audit-logs-111122223333/AWSLogs/111122223333/BedrockModelInvocationLogs/*",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "111122223333" },
        "ArnLike": { "aws:SourceArn": "arn:aws:bedrock:us-east-1:111122223333:*" }
      }
    }
  ]
}

---

IAM Least-Privilege Scoping & Guardrail Enforcement

Securing access to Amazon Bedrock models requires fine-grained IAM policy scoping. Unrestricted access granting bedrock:* on resource * introduces severe compliance and financial risks.

API Action Scoping

IAM policies must separate control-plane actions from data-plane model execution:

• Control Plane: bedrock:CreateGuardrail, bedrock:ListFoundationModels, bedrock:CreateCustomModel.
• Data Plane (Inference):
  • bedrock:InvokeModel: Used for standard synchronous model invocations.
  • bedrock:InvokeModelWithResponseStream: Used when applications consume real-time streaming token responses.
  • bedrock:ApplyGuardrail: Used to evaluate text against a guardrail independently of model invocation.

Enforcing Guardrail Attachment via IAM Condition Keys

A critical exam pattern involves preventing developers or application roles from bypassing security guardrails. If a developer possesses bedrock:InvokeModel permissions on a foundation model, they could theoretically invoke the model directly without referencing an approved Guardrail.

Security teams enforce mandatory guardrail compliance with the bedrock:GuardrailIdentifier condition key, whose value is the guardrail ARN with an optional version suffix (for example :1). Pair an Allow that requires the guardrail with an explicit Deny for any other value, so another policy can't grant an unguarded path:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowInvokeWithCorporateGuardrail",
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/*",
      "Condition": {
        "StringEquals": {
          "bedrock:GuardrailIdentifier": "arn:aws:bedrock:us-east-1:111122223333:guardrail/corp-production-guardrail:1"
        }
      }
    },
    {
      "Sid": "DenyInvokeWithoutCorporateGuardrail",
      "Effect": "Deny",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/*",
      "Condition": {
        "StringNotEquals": {
          "bedrock:GuardrailIdentifier": "arn:aws:bedrock:us-east-1:111122223333:guardrail/corp-production-guardrail:1"
        }
      }
    },
    {
      "Sid": "AllowApplyGuardrail",
      "Effect": "Allow",
      "Action": "bedrock:ApplyGuardrail",
      "Resource": "arn:aws:bedrock:us-east-1:111122223333:guardrail/corp-production-guardrail"
    }
  ]
}

---

Private Connectivity via AWS PrivateLink VPC Endpoints

Production workloads interacting with Amazon Bedrock should never traverse the public internet. By creating AWS PrivateLink Interface VPC Endpoints, application servers running in private subnets communicate with Bedrock APIs securely over the AWS private network backbone.

Loading diagram...

Distinct Service Endpoints in Bedrock

To achieve comprehensive private connectivity, security engineers must understand the distinct PrivateLink service names:

1. com.amazonaws.<region>.bedrock-runtime: The Data Plane endpoint required to invoke models (InvokeModel, InvokeModelWithResponseStream) and evaluate guardrails (ApplyGuardrail). This is the critical endpoint required by application workloads.
2. com.amazonaws.<region>.bedrock: The Control Plane endpoint used for administrative tasks, including creating guardrails, querying model IDs, and configuring fine-tuning jobs.
3. com.amazonaws.<region>.bedrock-agent-runtime: Required when applications interact with autonomous Bedrock Agents or execute knowledge base queries.

VPC Endpoint Policies

To enforce zero-trust boundary controls, attach an Interface VPC Endpoint Policy to the endpoint. The endpoint policy can restrict traffic exclusively to authorized AWS Organization accounts, specific foundation model ARNs, or specific corporate IAM roles, ensuring that compromised credentials cannot be used through the VPC endpoint to invoke unauthorized external models.

---

Specialty Exam Pitfalls & Architectural Traps

1. The 'Foundation Models Train on My Data' Distraction: Exam distractors frequently claim that foundation models hosted on Bedrock will incorporate proprietary prompt data into their global neural weights, requiring complex data obfuscation before API calls. This is false: Amazon Bedrock models do not use customer prompts or completions for training, and data remains logically isolated within the customer's AWS account.
2. Control Plane vs Runtime VPC Endpoint Confusion: A common failure scenario occurs when an engineer configures an interface endpoint for com.amazonaws.<region>.bedrock and discovers that application EC2 instances in private subnets still encounter network connection timeouts when calling InvokeModel. The reason: bedrock is the control plane endpoint; inference API calls require the bedrock-runtime endpoint.
3. KMS Permissions for Model Invocation Logging: Logging to an SSE-KMS bucket fails if the customer managed key's policy doesn't allow the Bedrock service principal (bedrock.amazonaws.com) to call kms:GenerateDataKey, and logging to CloudWatch Logs fails if the role Bedrock assumes lacks logs:CreateLogStream and logs:PutLogEvents.
4. Improper Output Handling (OWASP LLM05): Guardrails sanitize input prompts and model completions, but Guardrails cannot enforce application-level logic constraints. If an application takes model completions and blindly passes them into a database as dynamic SQL queries, the application remains vulnerable to SQL injection. All LLM completions must be treated as untrusted user input and handled with parameterized queries and strict schema validation.