Strands Guardrails
You set up strands guardrails by attaching filter rules to your AI agent loop. These rules check user text and model replies before the app shows them. Engineering teams use this setup to block bad prompts and toxic output. Yet broad agent roles still let approved prompts trigger risky tool actions. How strands guardrails work in an agent flow An AI agent works in a loop that reads text and runs tools. Native guardrails sit around the language model call inside that code loop. First, the in
AI Guardrails: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up strands guardrails by attaching filter rules to your AI agent loop. These rules check user text and model replies before the app shows them.
Engineering teams use this setup to block bad prompts and toxic output. Yet broad agent roles still let approved prompts trigger risky tool actions.
How strands guardrails work in an agent flow
An AI agent works in a loop that reads text and runs tools. Native guardrails sit around the language model call inside that code loop.
First, the input filter reads the user prompt before the model gets it. The filter checks the text against blocked topic lists and word patterns.
If the prompt matches a bad topic, the rule stops the loop early. The app then returns a safe fallback message to the end user.
If the prompt passes, the agent sends it to the language model. The model then writes a text reply or picks a tool to run.
Next, the output filter reads the model reply before the user sees it. It scans for sensitive data like emails, phone numbers, and card numbers.
Masking rules rewrite matched fields in results so raw numbers do not leak. Teams also add word filters to block rude or off-topic replies.
Where native prompt filters fall short
Native prompt filters solve text safety problems at the model layer. They stop toxic chat and catch plain text secrets in model replies.
Still, an agent does more than just chat with a user. Agents also run database queries, call internal APIs, and run shell tasks.
Prompt filters only check the text going into and out of the model. They do not inspect what individual database statements do in flight.
AI Guardrails: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Once the agent boots up, it holds static keys for your backend systems. Those keys often carry broad write or admin roles across whole databases.
A clever prompt can trick the model into picking a valid tool. The prompt looks clean to the filter, so the rule lets it pass.
The agent then sends a drop table query or reads ten thousand rows. Because the app role has broad permissions, the database runs the bad query.
Why tool calls need live action checks
Text rules cannot replace real controls on the tools an agent uses. Security teams need to check every single command before the target system runs it.
First, you should strip broad write roles from the agent service account. Give the agent read-only permissions on the specific tables it needs.
Second, separate safe read tools from risky write or delete tools. If an agent must change data, pause the run and ask a human.
Third, apply data masking at the database response level, not just in prompts. When a tool reads rows, masking rewrites matched fields in results right away.
This rewrites emails, phone numbers, and national IDs before the agent loop resumes. That way, sensitive values do not enter the model context window.
Finally, keep a full log of every tool call and database statement. Text logs show what the model said, while command logs show what ran.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What do strands guardrails filter in an AI app?
They filter user prompts and model text replies inside the agent loop. Teams use them to block harmful topics and rewrite emails or card numbers.
Can prompt guardrails stop an agent from running a bad SQL query?
No, prompt filters only check text around the language model call. You need database permission limits and command checks to block risky SQL statements.
How should teams handle high-risk agent tool calls?
Teams should split read tools from write tools and restrict agent credentials. For write actions, require a human to approve the command before it runs.