Governing AI Agents on AWS Bedrock: Decision Policies, Guardrails, and the Missing Audit Layer

AWS Bedrock has become the default foundation model platform for engineering teams already operating in the AWS ecosystem. The appeal is straightforward: Bedrock provides access to multiple foundation models through a unified API, integrates natively with IAM, CloudWatch, and other AWS services, and offers Bedrock Agents for building tool-using AI workflows without leaving the AWS control plane.

For teams building AI agents on Bedrock that make consequential decisions -- approving transactions, modifying customer records, generating communications, or executing business logic -- a governance question emerges that Bedrock's native capabilities address only partially. Bedrock Guardrails provides content-level safety: filtering inappropriate model outputs, redacting sensitive information, blocking denied topics, and grounding responses in retrieved context. These are necessary governance capabilities. They are also not the same thing as decision-level governance.

The distinction between model-output governance and decision-level governance is the gap that this article maps. For AWS-native engineering teams, understanding where Bedrock Guardrails provides coverage and where it does not is the starting point for building a governance architecture that satisfies not just content safety requirements but also policy enforcement, decision auditability, and regulatory compliance requirements.

What Bedrock Guardrails Does: Model-Output Governance

Bedrock Guardrails provides five categories of model-output governance that operate within the model inference pipeline:

Content filters. Configurable filters for hate speech, insults, sexual content, violence, and misconduct. Each category can be set to different sensitivity thresholds. Content filters evaluate the model's output text and block responses that exceed the configured thresholds.

Denied topics. Custom topic definitions that the model should not engage with. If the model's response touches a denied topic, the response is blocked and a default message is returned. Denied topics are defined using natural language descriptions, which Bedrock evaluates using a classifier.

Word filters. Explicit blocklists of words or phrases that should not appear in model outputs. Word filters operate at the lexical level -- they match exact strings, not semantic meaning.

Sensitive information filters. Detection and redaction of PII (personally identifiable information) and other sensitive data types in model outputs. Sensitive information filters can be configured to detect specific entity types (email addresses, phone numbers, SSNs) and either block the response or redact the sensitive entities.

Contextual grounding checks. Validation that the model's response is grounded in the provided context (from a knowledge base or retrieval-augmented generation pipeline) and does not hallucinate facts. Grounding checks compare the model's claims against the source context and filter responses that contain unsupported assertions.

Each of these capabilities operates at the model-output level. They evaluate what the model says, filter what the model produces, and ensure that the content reaching the user meets safety and quality standards. For content governance, this is the right abstraction level.

Where the Gap Is: Decision-Level Governance

Decision-level governance addresses a different set of questions than content governance. The distinction is clearest through examples:

The pattern is consistent: Bedrock Guardrails governs the model's language. It does not govern the agent's actions. An agent can produce a perfectly safe, non-toxic, PII-free, grounded response that proposes to approve a transaction the agent is not authorized to approve, delegate a task to an agent that should not receive it, or execute an action that violates an organizational policy. Guardrails will not catch these violations because they are not content violations -- they are decision authority violations.

This is not a criticism of Bedrock Guardrails. Content governance and decision governance are different layers with different responsibilities. The issue arises when teams assume that Bedrock Guardrails covers both layers and discover the gap only when an unauthorized action is taken, an auditor requests a decision trace that does not exist, or a policy change needs to be made without redeploying the application.

Mapping the Five Governance Gaps

For AWS-native teams building consequential AI agents on Bedrock, five specific governance gaps emerge between what Bedrock provides natively and what production governance requires. Each gap has a concrete failure mode.

Gap 1: Policy Enforcement at the Action Level

Bedrock Agents execute actions through action groups -- Lambda functions or API endpoints that the agent can invoke based on the model's tool-use decisions. Bedrock does not evaluate whether the agent should be permitted to invoke a specific action group with specific parameters in a specific context. The model decides which action to take; the action group executes. Between the model's decision and the execution, there is no policy evaluation layer.

The failure mode: an agent invokes an action that is technically available (the Lambda function exists and the IAM role permits invocation) but is not authorized by organizational policy (the agent should not approve transactions over $10,000, but the Lambda function accepts any amount). IAM controls who can invoke the function; they do not control the business logic of what parameters are acceptable in what contexts.

Gap 2: Decision-Level Audit Trails

Bedrock provides CloudWatch logging for model invocations, including input prompts, output completions, and guardrail evaluation results. This is model-level observability. It tells you what the model said and whether the guardrails filtered it. It does not tell you what decision was made, what policy governed it, what version of the policy was active, or what the decision's downstream impact was.

The failure mode: an auditor asks to see the complete decision record for a specific agent action from three months ago. The team produces a CloudWatch log entry showing the model's input and output. The auditor asks: "What policy governed this decision?" The team cannot answer from the log. The auditor asks: "Has the policy changed since this decision was made?" The team cannot answer definitively. The NIST AI Risk Management Framework requires that organizations maintain records sufficient to trace AI decisions back to the logic that produced them -- CloudWatch model invocation logs do not satisfy this requirement for decision-level actions.

Gap 3: Delegation Authority Control

Bedrock Agents support multi-agent collaboration through agent-to-agent invocation. Agent A can invoke Agent B as a tool, passing context and receiving results. Bedrock manages the invocation mechanics -- routing, context serialization, and response handling. It does not evaluate whether Agent A should be permitted to delegate to Agent B for a specific task, whether the delegation escalates authority (Agent B has access to actions that Agent A does not), or whether the delegation context is complete (did Agent A propagate the user's authorization scope to Agent B?).

The failure mode: a triage agent delegates a financial analysis task to a specialist agent. The specialist agent has access to trading execution APIs that the triage agent does not. The delegation is technically valid (the agent invocation succeeds), but the user's original request was for information, not execution. The specialist agent, interpreting the delegated task broadly, executes a trade. No governance layer evaluated whether the delegation should have been permitted or whether the specialist agent's action exceeded the scope of the original request.

Gap 4: Policy Versioning Independent of Deployment

Bedrock Guardrails configurations are defined in the AWS console or through API calls. When a guardrail configuration is updated, the new configuration applies immediately to all subsequent model invocations. There is no native mechanism for versioning guardrail configurations independently of the application, running new configurations in shadow mode against production traffic, or rolling back to a previous configuration with a single operation.

Bedrock does support guardrail versioning -- you can create new versions of a guardrail configuration. But the versioning is at the content-filter level, not the decision-policy level. You can version your content safety rules; you cannot version your business decision policies because those policies do not exist in Bedrock as first-class objects.

The failure mode: a policy change is deployed by updating the agent's prompt instructions or action group logic. The previous policy is overwritten. Two weeks later, a question arises about decisions made under the previous policy. There is no immutable snapshot of the previous policy as it existed at the time those decisions were made.

Gap 5: Cross-Action Constraint Enforcement

Bedrock evaluates each model invocation independently. There is no native mechanism for enforcing constraints that span multiple invocations: cumulative spend limits across a session, rate limits on specific action types within a time window, or sequential constraints (action B should not be permitted until action A has been completed and verified).

The failure mode: an agent approves five separate $9,000 expenses in a single session, each individually below the $10,000 single-transaction limit but collectively totaling $45,000 -- well above the $25,000 session limit that the organization intended to enforce. Each individual invocation passes every check; the cumulative violation is invisible because no layer is tracking cross-invocation state.

Architecture: The Decision Plane Layer for Bedrock

The architecture that fills these gaps adds a decision plane between the Bedrock agent's action decisions and the action execution. The decision plane does not replace Bedrock Guardrails -- content governance continues to operate within the model inference pipeline where it belongs. The decision plane adds decision governance at the action boundary.

# Bedrock agent governance architecture

User Request
    |
    v
Bedrock Agent (model inference)
    |
    v
Bedrock Guardrails (content governance)
    - Content filters
    - Denied topics
    - PII redaction
    - Grounding checks
    |
    v
Agent proposes action (tool use / action group invocation)
    |
    v
Decision Plane (decision governance)          <-- New layer
    - Policy evaluation against versioned rules
    - Authorization check (is this agent permitted this action?)
    - Cross-action constraint check (cumulative limits, rate limits)
    - Delegation authority check (if multi-agent)
    - Decision trace generation (immutable audit record)
    |
    +---> If permitted: Action Group executes (Lambda / API)
    |         |
    |         v
    |     Decision trace recorded (inputs, rule, version, outcome)
    |
    +---> If denied: Denial returned to agent with reason
              |
              v
          Decision trace recorded (inputs, rule, version, denial reason)

The decision plane integrates at the action group invocation boundary. When the Bedrock agent decides to invoke an action group, the invocation request is intercepted by the decision plane before execution. The decision plane evaluates the proposed action against the active policy rules, checks cross-action constraints, and either permits or denies the action. In both cases, the decision is recorded as an immutable trace.

For AWS-native teams, the decision plane can be implemented as a Lambda function that wraps the action group invocation, an API Gateway authorizer that evaluates policy before routing to the action endpoint, or a Step Functions state that evaluates policy as a step in the agent's execution workflow. The implementation pattern varies; the architectural requirement is consistent: every consequential action passes through a policy evaluation gate before execution.

What the Decision Trace Contains (That CloudWatch Does Not)

The decision trace generated by the decision plane captures information that CloudWatch model invocation logs do not contain:

# Decision trace for a Bedrock agent action
trace:
  id: "dt-bedrock-20260619-04471"
  timestamp: "2026-06-19T10:14:33Z"
  agent:
    bedrock_agent_id: "AGENT-7X9K2M"
    agent_alias: "expense-approval-v3"
  action:
    action_group: "approve-expense"
    parameters:
      expense_id: "exp-88234"
      amount_usd: 12500
      category: "consulting"
      department: "engineering"
  policy_evaluation:
    rules_evaluated:
      - name: "single-transaction-limit"
        version: "3.0.1"
        result: "pass"
        detail: "12500 <= 15000 (engineering department limit)"
      - name: "consulting-category-review"
        version: "1.2.0"
        result: "escalate"
        detail: "consulting expenses > 10000 require manager review"
    cumulative_checks:
      - name: "session-spend-limit"
        version: "2.0.0"
        session_total: 28500
        limit: 50000
        result: "pass"
    outcome: "escalate"
    reason: "consulting-category-review requires manager approval"
  context:
    user_id: "user-4412"
    session_id: "sess-20260619-0877"
    iam_role: "bedrock-agent-expense-role"
  delegation_chain: null

This trace answers every question an auditor would ask: what action was proposed, what rules evaluated it, what version of each rule was active, what the cumulative session state was, and what the outcome was. The CloudWatch log for the same event would show the model's input tokens, output tokens, latency, and guardrail filter results -- valuable for debugging model behavior, but insufficient for reconstructing the governance rationale behind the decision.

Implementation Path for AWS-Native Teams

For teams with existing Bedrock agent deployments, adding the decision plane follows a phased approach that does not require rebuilding the agent architecture:

Phase 1: Instrument action boundaries (weeks 1-2). Add logging at every action group invocation point. Capture the proposed action, its parameters, and the context. This establishes visibility into what actions the agent is taking before adding any enforcement. Use CloudWatch custom metrics or a dedicated decision log store (DynamoDB with point-in-time recovery works well for immutable append-only records in AWS environments).

Phase 2: Define policy rules (weeks 2-3). Based on the action boundary logs from Phase 1, define the policy rules that should govern each action type. For each action group, identify: what parameters should be constrained, what authorization checks should apply, what cross-action limits should exist, and what escalation paths should be defined. Store policy rules as versioned documents in S3 or DynamoDB -- not in the agent's prompt instructions or Lambda code.

Phase 3: Deploy in shadow mode (weeks 3-5). Implement the decision plane as a wrapper around action group invocations. In shadow mode, the decision plane evaluates every proposed action against the policy rules and records the result, but does not enforce it. The action proceeds regardless of the policy evaluation outcome. Shadow mode produces a shadow diff: the comparison between what the system actually did and what it would have done if the policy had been enforced.

Phase 4: Enable enforcement (weeks 5-7). After reviewing the shadow diff and confirming that the policy rules produce expected outcomes, enable enforcement. Start with the highest-consequence action groups -- financial transactions, data modifications, external communications -- and expand to lower-consequence actions based on shadow observation.

The total timeline is 6 to 9 weeks for a single Bedrock agent deployment. Teams with multiple agents can parallelize Phases 1 and 2 across agents and share the decision plane infrastructure deployed in Phases 3 and 4. Gartner's research on enterprise AI governance for AWS deployments identifies the absence of a decision-level governance layer as the most common gap in enterprise Bedrock deployments and recommends a phased implementation approach consistent with this timeline.

Bedrock Guardrails and Decision Plane: Complementary, Not Competing

The correct architecture uses both layers. Bedrock Guardrails handles content governance within the model inference pipeline: it ensures that the model's outputs are safe, appropriate, and grounded. The decision plane handles decision governance at the action boundary: it ensures that the agent's actions are authorized, policy-compliant, and auditable.

Removing Bedrock Guardrails because you have a decision plane would leave the system exposed to content safety risks. Relying solely on Bedrock Guardrails without a decision plane leaves the system exposed to unauthorized actions, unaudited decisions, and policy enforcement gaps. The two layers address different threat models and should be deployed together.

For AWS-native teams, the layered architecture integrates naturally with existing AWS services. Bedrock Guardrails runs within the Bedrock service. The decision plane runs as a Lambda function, Step Functions state, or API Gateway authorizer -- all native AWS primitives that integrate with IAM, CloudWatch, and CloudTrail. The decision trace store can be DynamoDB with point-in-time recovery, S3 with object lock for immutability, or a purpose-built audit log service. The entire governance stack stays within the AWS control plane.

The question for teams building on Bedrock is not whether they need governance beyond Guardrails. If their agents take consequential actions, they do. The question is whether they build the decision plane before the first governance incident or after it. The teams that build it before report fewer incidents, faster audit responses, and higher confidence from compliance stakeholders. The teams that build it after report the same outcomes -- just later, at higher cost, and with a governance gap in their incident history that auditors will notice.