Guardrails and AI Agent Security

What it is

A model will answer what it is asked, including things you did not intend. Amazon Bedrock Guardrails adds a configurable check on what goes into the model and what comes out.

An agent goes further: it decides to call tools, such as APIs and databases, on a user's behalf. Securing an agent means authorizing each tool call, separating one user's session from another's, and asking a human before sensitive actions.

The exam guide treats designing AI safety frameworks as out of scope. Your job is to configure and call these controls correctly.

How it works

What a guardrail can filter

You create a guardrail with one or more policies and a message to return when something is blocked.

Masking replaces a detected value with a placeholder such as {EMAIL}. Blocking replaces the whole message with your configured text.

Using a guardrail in code

Create a guardrail, then create a version. Applications should reference a numbered version rather than the working DRAFT.

• Converse and ConverseStream: add guardrailConfig with guardrailIdentifier, guardrailVersion and optionally trace set to enabled.
• InvokeModel: pass the guardrail identifier and version with the request.
• ApplyGuardrail: a separate API that checks any text against a guardrail without calling a model. Use it to screen content that does not go through a model call, or text from another source.

When a guardrail steps in, the response stopReason is guardrail_intervened. Masking also returns this same stop reason, so you cannot tell a block from a mask by stopReason. Read the trace: the action is BLOCKED or ANONYMIZED.

Use a guardContent block to tell the guardrail which part of a message to evaluate. Once any guardContent block exists, only the content inside those blocks is evaluated. A system prompt is checked only if you wrap it in guardContent.

Two limits matter. With Converse tool use, a guardrail does not evaluate tool results your application returns, tool definitions, or the arguments the model generates for a tool call. Check those yourself. Also, the trace includes the unmasked values, so protect it like sensitive data.

Securing agent interactions

Tool authorization. Give the agent's role only the actions its tools need. For tools behind Amazon Bedrock AgentCore Gateway, inbound callers are authorized with a JWT from an identity provider such as Amazon Cognito, or with IAM credentials. Do not use a gateway set to no authorization in production.

Amazon Bedrock AgentCore Identity manages agent identities and credentials, so an agent can act for a user without secrets in code.

Session isolation. Amazon Bedrock AgentCore Runtime gives each session its own microVM, and clears its memory when the session ends. Your application must create a unique session ID for each user (at least 33 characters) and keep the user to session mapping, because AgentCore does not enforce it. Session context keys such as aws:AgentCoreRuntimeSourceSid let one execution role policy limit each session to its own S3 prefix.

Human approval. A tool result can contain text that tells the agent to take another action, which is an indirect prompt injection. In Amazon Bedrock Agents you can turn on user confirmation for an action group function. The agent then returns the proposed call, the user chooses CONFIRM or DENY, and your code sends that answer back in the next InvokeAgent request as confirmationState. With DENY the call does not run. Return of control lets your application run the action itself instead of the agent calling it.

How the exam asks about this

• "Customer emails must be redacted from model answers" -> a sensitive information filter set to mask.
• "The agent can delete records; ensure the user approves first" -> enable user confirmation for that action.
• "Users must not see each other's agent state" -> a unique runtime session ID per user, with isolated sessions.