Amazon Bedrock Agents in Production: A PSF Domain Assessment

Guardrails for Amazon Bedrock provides content filtering for input topics, PII detection, and prompt injection detection. Configuration is required — no defaults apply.

Amazon Bedrock's Guardrails feature is a configurable content moderation layer that can be applied to agent inputs and model responses. It provides: topic filtering (deny lists for out-of-scope subjects), content filtering (harmful content categories with configurable severity thresholds), PII detection and handling (redaction or blocking), word filters, and prompt injection detection. These controls are more comprehensive than anything natively available in code-first frameworks — the configuration UI in the AWS console allows non-engineers to define input governance policies. The critical caveat for PSF Domain 1 is that Guardrails are not applied by default. An agent created without an associated Guardrail configuration processes all inputs without screening. Many Bedrock agent deployments skip Guardrails during initial development and never add them in production. Practitioners must explicitly create a Guardrail, define its policies, and associate it with every agent or knowledge base that handles untrusted input.

Guardrails applies to model outputs as well as inputs, providing content filtering and PII scrubbing. Structured output schema enforcement for action groups provides schema-level validation.

Bedrock Guardrails's output filtering checks model responses against the same content policies as inputs, and can redact PII before responses reach the caller. For agents using action groups (the Bedrock equivalent of tool calls), the action group's OpenAPI schema provides structural validation of action arguments. This covers a meaningful slice of PSF Domain 2. The gap is in semantic output validation: Guardrails checks for policy violations and sensitive content, but does not evaluate whether a response is factually appropriate, within the agent's knowledge boundary, or appropriately scoped to the query. For high-stakes outputs — financial recommendations, medical information, legal guidance — structural and content filtering is insufficient. A response can pass all Guardrail checks while still being confidently wrong. Practitioners in regulated industries must implement a semantic validation step beyond Guardrails.

AWS data protection controls — VPC endpoints, KMS encryption, CloudTrail logging, AWS Config rules — provide enterprise-grade data governance for Bedrock deployments.

Data protection is Amazon Bedrock's strongest PSF domain, primarily because it inherits the full AWS security and compliance stack. Bedrock API calls can be routed through VPC endpoints, keeping model inference traffic entirely within your network perimeter. Knowledge base content is encrypted at rest in S3 and in the vector store (OpenSearch Serverless, Aurora, Pinecone, etc.) using KMS keys under your control. By default, Amazon does not use inputs submitted to Bedrock to train models — this is a contractual commitment explicitly documented in the AWS service terms, critical for regulated data deployments. AWS's compliance certifications (ISO 27001, SOC 2, HIPAA BAA, PCI DSS) extend to Bedrock. Bedrock Guardrails's PII anonymisation provides input scrubbing before model processing. For organisations with strict data residency requirements, Bedrock model inference can be constrained to specific AWS regions. This is the most comprehensive native data protection posture of any framework assessed.

CloudWatch integration provides metrics, logs, and alarms. CloudTrail logs all Bedrock API activity. Bedrock-native invocation logging captures full input/output traces.

Bedrock's observability story is strong for AWS-native deployments. CloudWatch collects Bedrock invocation metrics — latency, token usage, error rates, throttle rates — with configurable alarm thresholds and dashboards. Bedrock invocation logging captures full input/output pairs to S3 or CloudWatch Logs, providing the trace depth needed for incident investigation. CloudTrail's Bedrock event logging records every API call with caller identity, timestamp, and request parameters, providing an unalterable audit log. For agent sessions, Bedrock logs session-level traces that reconstruct the orchestration chain — which knowledge base was queried, which action group was invoked, what inputs and outputs were at each step. The limitation is that this observability is only available within the AWS ecosystem: teams using multi-cloud monitoring or wanting to correlate Bedrock traces with non-AWS services need to export data to their central observability platform, which requires explicit pipeline configuration.

Agent versioning and aliases provide stable deployment targets. No built-in canary rollout or automated rollback — these require custom implementation via Lambda and CloudWatch.

Bedrock Agents's versioning model is one of the more thoughtful in the framework ecosystem. Agents support explicit versioning: each saved version is immutable, and aliases (named pointers like PROD, STAGING, V2-TEST) allow stable deployment targets that can be redirected to new versions without changing caller configurations. This is a solid foundation for deployment safety. The gaps are in the deployment process itself: there is no native canary routing that splits traffic between two agent versions based on a percentage. Routing all traffic from STAGING to PROD is an instant cut-over. Automated rollback requires custom implementation — a CloudWatch alarm that triggers a Lambda to update an alias back to the previous version. These patterns are achievable within the AWS ecosystem but require practitioner effort. For large-scale enterprise deployments, this is a gap that teams moving from traditional software deployment practices will feel acutely.

Human-in-the-loop for agent action group confirmations can be implemented via return_of_control. No native approval queue or structured case management.

Bedrock Agents supports a return_of_control mechanism: when an agent needs to execute an action group step, the response can be configured to return control to the calling application rather than proceeding autonomously. The calling application receives the pending action details, can present them to a human for approval, and resumes the agent session with an approved or rejected response. This enables human oversight gates on consequential agent actions. The limitation is in the surrounding infrastructure: Bedrock provides the pause-and-resume primitive but not the approval queue, reviewer interface, audit log, or escalation logic that a production human oversight system requires. Practitioners must build these application-layer components. For multi-agent workflows using the Bedrock supervisor pattern, human oversight at intermediate steps requires careful routing of return_of_control responses through the full orchestration stack.

IAM role-based access control provides granular least-privilege enforcement. Action group Lambda functions operate with their own IAM roles. KMS key policies control data access. VPC isolation available.

Security is Amazon Bedrock's second-strongest PSF domain, again due to AWS infrastructure inheritance. IAM provides fine-grained control over who and what can invoke Bedrock agents, access knowledge bases, and call action group APIs. Action group Lambda functions execute under their own IAM service roles with resource-scoped permissions — this enforces least-privilege at the tool execution layer, which is a meaningful security property absent from all code-first frameworks. Bedrock's VPC integration prevents model inference traffic from traversing the public internet. AWS Security Hub's Bedrock controls provide automated security posture assessment. The primary security risk in Bedrock agent deployments is misconfigured action group permissions: Lambda functions with overly broad IAM roles can be induced to take unintended actions through prompt injection. The solution is the same as any AWS security discipline: scope IAM roles to the minimum permissions the function actually needs.

Multi-model support within Bedrock provides some provider resilience. AWS region redundancy is available. Hard dependency on AWS infrastructure creates platform concentration risk.

Bedrock's model portfolio — Claude, Titan, Llama, Mistral, Cohere, and others accessible through a unified API — provides meaningful provider-within-platform resilience. Switching from Claude 3 Sonnet to Claude 3.5 Haiku, or from Claude to Llama for non-sensitive workloads, is a configuration change. Cross-region inference profiles allow Bedrock to route requests to the model in whichever region has capacity, improving availability. The resilience limitation is platform concentration: all of this runs on AWS. An organisation whose entire AI deployment is Bedrock-on-AWS has a single infrastructure provider dependency. For organisations already heavily invested in AWS this is often an acceptable risk posture — AWS's SLA and redundancy architecture is enterprise-grade. For organisations with multi-cloud requirements or competitive concerns about AWS infrastructure dependency, Bedrock's tight AWS integration is a constraint.