SAP-C03 Responsible AI Controls: Amazon Bedrock Guardrails, AgentCore Identity and Policy, and Human Approval with Step Functions

Responsible-AI requirements on AWS split into four questions, and each has its own control. What may the model read and say? is answered by Amazon Bedrock Guardrails. Who may call the agent, and with whose credentials does the agent call other systems? is answered by Amazon Bedrock AgentCore Identity. Which tool calls may an agent make, with which inputs? is answered by Policy in Amazon Bedrock AgentCore at the gateway. Which actions need a person to approve them first? is answered by a human-oversight workflow, usually AWS Step Functions with a task token, or the built-in action controls of an Amazon Bedrock agent.

Guardrails are probabilistic text and image classifiers (Automated Reasoning aside). They are the wrong tool when the requirement says "deterministic", "however the agent is coded" or "a person must approve". Those requirements need an authorization rule or a workflow outside the model and outside agent code. Model access, AgentCore Gateway tool design and model invocation logging belong to sibling topics; this lesson covers the controls themselves (SAP-C03 Task 2.5).

A guardrail is a reusable set of policies that Amazon Bedrock evaluates on user input and on model output. Each policy has its own job, and many exam distractors are a real policy used for the wrong job:

Denied topics versus word filters

Use a denied topic when the requirement is "refuse this kind of request, however it is phrased", for example legal advice or speculation about unannounced products. Use a word filter when the requirement is a fixed list of strings that must never appear, such as specific brand names or profanity. The two combine well: a topic blocks the subject, a word filter blocks the exact terms even in otherwise acceptable answers. A word list of subject phrases misses rewordings, and a denied topic defined as a list of names is still a meaning-based check, not an exact match. The Misconduct content category covers criminal or harmful activity, not business-compliance subjects.

Sensitive information: block or mask

BLOCK rejects the whole prompt or response when an entity is found. ANONYMIZE replaces each detected value with a label such as {NAME} or {PHONE} and lets the rest through, which is what you want when every request must still produce output (for example a ticket summary stored for support staff) but the values must not appear in it. A company-specific identifier format (say two letters, a hyphen and five digits) needs a regex entity; built-in types cover common PII.

Masking changes what the model sees and returns. It does not change Amazon Bedrock model invocation logs: the logged request always holds the original input, so PII that a user typed reaches the log group. To let people keep reading those logs without seeing identifiers, attach an Amazon CloudWatch Logs data protection policy to the log group; it masks detected identifiers for anyone without the logs:Unmask permission. Controls on who may open the log group, or on what the guardrail does to the response, leave the stored log text itself unchanged.

The prompt attack filter screens user input for jailbreaks and injected instructions. It has nothing to evaluate on the output side: an injected instruction is caught before the model acts on it, not in what the model writes afterwards.

Input tags separate your instructions from user text

With InvokeModel, the request body is one block of text, so the guardrail cannot tell the developer's system prompt from the user's message. A long, instruction-heavy system prompt can itself look like an override attempt and get legitimate requests blocked. Wrap only the user-supplied text in the guardrail input tags (amazon-bedrock-guardrails-guardContent_<suffix>, with a suffix you choose per request); the guardrail then evaluates only the tagged content. The Converse API does the same with guardContent blocks. Lowering the filter strength instead simply trades away protection.

Tagging is selective evaluation chosen by the caller. That is useful, but it also means a caller can tag a harmless greeting and leave the rest of the prompt unevaluated. Responses are always guarded. Where every prompt must be evaluated in full whatever callers tag, use a guardrail enforcement with comprehensive content guarding (see the section on applying guardrails everywhere).

Detect mode: measure before you block

Each filter has a strength (how sensitive detection is) and an action per direction (what happens on detection). Setting the input and output action to NONE while keeping the intended strength puts the filter in detect mode: nothing is blocked, and the guardrail trace records each assessment as detected but not acted on. Run that on production traffic, review the false positives, then switch the action to BLOCK. Detect mode is set by the filter action; the filter strength controls how sensitive detection is, and a filter whose strength is off detects nothing to review.

Images

Content filters can be applied to the image modality as well as text, for categories such as Violence and Sexual, on input and output. Image evaluation is a modality you turn on per filter; denied topics and word filters work on text only.

Content filters, prompt attack detection and denied topics come in two safeguard tiers, and the choice is mostly a trade between capability and where processing happens:

Two consequences follow. A workload that needs languages beyond English, French and Spanish, or detection inside generated code, needs the Standard tier and a guardrail profile, and choosing a US or EU profile keeps processing inside that geography. A workload whose regulator allows processing in one Region only stays on the Classic tier with no profile, which is acceptable when its users write only English, French or Spanish. The guardrail profile belongs to the guardrail itself; inference settings for the model are configured independently.

Streaming responses

When responses stream (InvokeModelWithResponseStream, ConverseStream), the guardrail runs in one of two modes:

• Synchronous (default): chunks are buffered and evaluated before they are sent. Every chunk is checked and masking works, at the cost of some added latency.
• Asynchronous: chunks are sent immediately and evaluated in the background. Latency is lowest, but harmful text can be shown briefly before the guardrail intervenes, and masking of sensitive information is not supported.

Choose asynchronous only when brief exposure is acceptable (for example an internal tool where the guardrail is a secondary safeguard) and no masking is required. If either "never displayed, even briefly" or "must mask" appears, the answer is synchronous, while keeping streaming if the requirement says so.

Both detect wrong answers, but they decide in different ways and fit different requirements:

Making the grounding check actually run

The grounding check needs three inputs, and it only treats text as reference or question when you label it. With the Converse or ApplyGuardrail APIs, send the retrieved passages and the user question as guardContent blocks qualified grounding_source and query; the model's response is the content guarded. Passages placed in a system prompt or an ordinary message are not used as the reference, so the check never intervenes, and raising thresholds or enabling input checking cannot fix inputs that are missing. A grounding failure is an answer that adds facts the source lacks; a relevance failure is an accurate passage that does not answer what was asked.

Automated Reasoning and enforcement

Automated Reasoning policies are not supported in account- or organization-level guardrail enforcements and cause runtime failures there. When one team needs rule-based validation on top of an enforced baseline, put the Automated Reasoning policy in a separate guardrail that the team's application names in its requests; the enforced baseline and the request guardrail both apply. Offline model evaluation jobs and LLM judges score samples later; they do not check each answer at runtime.

There are four ways a guardrail reaches a model call, from weakest to strongest guarantee:

ApplyGuardrail for models outside Amazon Bedrock

ApplyGuardrail takes text, a guardrail and a source: INPUT for a user prompt, OUTPUT for a model response. It returns the assessment and any masked text. That lets one guardrail definition protect a model on a SageMaker AI endpoint, a model self-hosted on Amazon EKS, or a third-party provider's API. Because each direction has its own policies (prompt attack detection is input-only), a complete integration calls it twice: source INPUT on the prompt before the model, source OUTPUT on the answer before returning it. Moving the model into Bedrock is not required.

Enforcing with IAM

A policy that allows bedrock:InvokeModel (and Converse, streaming variants) only when bedrock:GuardrailIdentifier equals the approved guardrail-arn:version, plus an explicit Deny for any other value, forces callers to name it. Applying the guardrail is itself authorized separately, so the role also needs an Allow for bedrock:ApplyGuardrail on the guardrail ARN; a role that never used guardrails before fails with AccessDenied until that is added. Two documented limits matter:

• RetrieveAndGenerate, InvokeAgent and InvokeInlineAgent make several model calls for you, and some do not carry the guardrail, so an enforced role gets AccessDenied. Use Retrieve followed by a Converse call that names the guardrail, or use an enforcement instead.
• A caller can still use input tags to limit which part of its prompt is evaluated.

Account- and organization-level enforcement

For an organization, the setup lives in the management account: create the guardrail and a numbered version, add a resource-based policy that lets the organization call bedrock:ApplyGuardrail on it (member-account roles also need an identity-policy Allow for bedrock:ApplyGuardrail on that guardrail; the resource policy alone is not enough), enable the Amazon Bedrock policy type in AWS Organizations, and attach a Bedrock policy to the root, OUs or accounts. Accounts that later join an OU inherit it. Account-level enforcement does the same within one account. Design points:

• Regional: the policy maps each Region to a guardrail ARN and version in that Region. A Region with no mapping has no enforced guardrail; guardrail cross-Region inference does not change this.
• Model scope: include or exclude models, for example excluding embedding models so document ingestion is not evaluated and billed.
• Content guarding for system prompts and messages: selective honours callers' input tags, comprehensive evaluates everything regardless of tags.
• Layering: an enforced guardrail and a guardrail named in the request both apply. The effective protection is the union of their controls, and where both set the same control the more restrictive setting wins. A team cannot loosen the baseline by naming a laxer guardrail; it can only add controls.
• Policy inheritance is different: when several Amazon Bedrock policies are attached at the root, an OU and an account, AWS Organizations resolves them by declarative inheritance into one effective policy for each account. The union rule applies to guardrails at different levels (organization, account, request), not to the policy documents themselves.

An SCP that denies calls without the condition key still requires every team to change its code, and invocation logging with an alerting function only detects after the fact.

Versions and encryption

Every guardrail has a mutable DRAFT and immutable numbered versions created with CreateGuardrailVersion. Anything that references DRAFT picks up every edit on its next request, so production and enforcements should reference a numbered version; promotion is a deliberate change of version number, and rollback is switching back. A guardrail encrypted with a customer managed KMS key needs key permissions in the key policy and the identity policy: people who create or manage it need kms:Decrypt, kms:GenerateDataKey, kms:DescribeKey and kms:CreateGrant, while roles that only use it during inference or agent invocation need just kms:Decrypt.

An agent on Amazon Bedrock AgentCore Runtime, or an AgentCore Gateway, accepts callers through one inbound mechanism: IAM SigV4 or a JWT authorizer, not both on the same resource. SigV4 suits AWS workloads that already hold IAM credentials. A JWT authorizer suits users who sign in to a corporate or customer identity provider (Okta, Microsoft Entra ID, Amazon Cognito and others), because neither the users nor the web application need AWS credentials; the application forwards the user's bearer token.

JWT authorizer settings

Every configured check must pass. When one IdP issues tokens to dozens of applications, signature validation alone admits all of them; narrow with allowed clients (which app) and a custom claim (which users). A check only narrows access if the value it tests differs between the callers you want and the ones you don't.

Making the gateway the only way in

With a JWT authorizer, the token proves the user, so a user with a valid token can call the runtime's endpoint directly and skip controls applied at a gateway in front of it (policies, guardrails). Client and audience checks do not help, because the token is the same on both paths. Pin the runtime to its gateway by listing the gateway's ARN in the authorizer's allowed workload configuration. For a SigV4 runtime, the equivalent is a resource policy that allows only the gateway's execution role.

Passing a user identity with SigV4

A trusted back end that invokes a runtime with SigV4 can pass a user ID in the X-Amzn-Bedrock-AgentCore-Runtime-User-Id header, so the agent retrieves that user's stored tokens. The header is not verified against an authenticated user. Calls that carry it need the separate bedrock-agentcore:InvokeAgentRuntimeForUser permission: grant it only to the trusted back-end role, leave other roles with plain InvokeAgentRuntime, and derive the user ID from the authenticated session, never from client input.

Outbound access is the other half of AgentCore Identity: the agent never holds long-lived secrets in code, environment variables, prompts or tool specifications. Instead, credential providers in AgentCore Identity hold OAuth client secrets and API keys, and the token vault stores OAuth tokens obtained for users, encrypted with AWS KMS. Pick the provider from whose permissions the call must carry:

The token vault binds tokens to agent and user

When a runtime receives a validated user JWT, it derives a workload access token for that agent identity and that user. The token vault releases stored OAuth tokens only against a matching workload access token, so one user's SaaS tokens cannot be used in another user's session. The AgentCore SDK decorators (such as @requires_access_token) handle the flow: if consent is still needed, they return an authorization URL for the user. A self-built token store loses that agent-and-user binding, and it is the kind of custom secret storage the service exists to remove. A client-credentials grant or a shared API key acts as the application, not the user.

Token exchange versus passthrough

Token passthrough forwards the user's original inbound JWT unchanged: no agent identity, no scoping to the downstream resource. It is available only for AgentCore Runtime targets (and needs a JWT or no inbound authorizer), not for MCP server, OpenAPI, Lambda, API Gateway or Smithy targets. Token exchange replaces it with a new token scoped to the target that carries both identities.

The gateway execution role is a ceiling

Every target that uses the gateway's IAM role (GATEWAY_IAM_ROLE) shares that one role, so its permissions are the upper bound for any caller the gateway admits. If a public product-search tool and an HR records tool sit behind the same gateway, a compromise of the customer path can reach anything the role can reach. Separate trust boundaries with separate gateways, each with its own minimally scoped execution role (no wildcards: each role invokes only its own targets' functions). A policy rule on a shared gateway reduces the blast radius but remains a rule that can be misconfigured; only separate roles give separate ceilings.

Policy in AgentCore is deterministic authorization for tool calls. A policy engine holding Cedar policies is associated with an AgentCore Gateway, and the gateway evaluates every tool request against it before forwarding: the principal (claims from the caller's token, such as a role or group), the tool being called and its input parameters (for example a transfer limit). permit and forbid rules decide; a forbid always wins.

Because the check runs at the gateway, it holds whatever the prompt says, whatever a prompt injection achieves and however an agent is coded. That is the difference from the alternatives:

• A guardrail classifies text probabilistically; it cannot guarantee that a parameter never exceeds a limit.
• System-prompt instructions are guidance to the model, not enforcement.
• The gateway execution role sees only which target is invoked, not which user asked or with what arguments.

Rolling it out safely

A policy engine runs in one of two modes. LOG_ONLY evaluates each call and logs whether it would be allowed or denied without blocking anything, which lets you validate rules against real production traffic so no agent loses tool access. ENFORCE blocks denied calls. Anyone allowed bedrock-agentcore:UpdateGateway can switch a gateway from ENFORCE back to LOG_ONLY or remove the policy engine, and there is no separate action or condition key protecting the mode, so restrict UpdateGateway to a few trusted administrator roles. Denying InvokeGateway stops people using the gateway, not changing it.

Human oversight means a high-impact AI output or action waits for an authorized person's decision, and the system resumes automatically when that decision arrives. On AWS the standard design is an AWS Step Functions Standard workflow using the callback pattern:

1. A task with the .waitForTaskToken integration passes the task token ($$.Task.Token) to a notifier: Amazon SNS email, an SQS queue read by a review application, or a Lambda function.
2. The execution pauses. Standard workflows can wait up to a year, so days-long reviews are fine.
3. The approval endpoint calls SendTaskSuccess (approve, optionally with corrected data as output) or SendTaskFailure (reject). A Catch on the failure routes rejected items to a revision branch.

Express workflows do not support .waitForTaskToken (or .sync); they are request-response only and short-lived. A Lambda function that polls times out after 15 minutes, SQS delay queues cap at 15 minutes, and a fixed Wait state cannot react when the decision comes early. Amazon SageMaker Augmented AI (A2I) is no longer open to new customers, so a new account builds this with Step Functions and its own review UI.

Approval by email

For approvers who should not sign in to a new portal, the task's SNS email carries approve and reject links to an Amazon API Gateway endpoint; the links include the task token. A Lambda function behind the endpoint calls SendTaskSuccess or SendTaskFailure with it. The token identifies one specific waiting task, which is why the decision has to travel with it; anything that identifies only the workflow as a whole cannot resume that task.

Timeouts and escalation

TimeoutSeconds on the waiting task fails it with States.Timeout if nobody answers; a Catch on that error moves the item to an escalation path (for example a second waiting task for a manager). HeartbeatSeconds fails the task with a timeout error if no SendTaskHeartbeat arrives in time (the callback documentation reports States.Timeout; States.HeartbeatTimeout can also be caught), so catching States.Timeout covers both. Escalation means routing to a different decision-maker: retrying the same waiting step just re-sends the same request to the same person.

Cross-account approvals

A task token can only be returned by a principal in the workflow's own account. An approval portal in another account cannot complete the task with its own role, whatever its identity policy says; have it assume a role in the workflow's account that allows states:SendTaskSuccess and states:SendTaskFailure.

Route only what needs a human, and keep the agent out of the decision

Reviewing everything removes the value of automation. A Choice state compares the model's confidence or the action's risk score with a threshold: confident or low-risk items continue, the rest go to the waiting task. To make self-approval impossible even after a successful prompt injection, the agent may start the workflow but never receives the task token and has no states:SendTaskSuccess permission. Decisions return through a separate, authenticated approval API (behind the corporate IdP) whose own role completes the task and logs the approver's identity for audit. A guardrail that refuses risky content is not an approval step.

Built-in approval in Amazon Bedrock Agents

Amazon Bedrock Agents (the managed agents feature) have two built-in action controls, configured on the action group, that put a person or the application between the model's decision and the action:

AWS recommends user confirmation as a mitigation for indirect prompt injection, where instructions hidden in retrieved content (emails, documents) try to trigger a destructive function: the function cannot run without the user's explicit confirmation. Enable it only on the dangerous functions so the others keep running without prompts. A prompt attack filter lowers the chance of injection but does not create an approval.