Guardrails

An organisation has one guardrailGuardrailGuardrailA safety check on what goes into and comes out of a model — for example blocking harmful content or sensitive data. Admins set it for the organisation.Open in glossary policy; departments and agents carry none. The policy is off until an administrator switches it on under Guardrails in the Admin console, which needs org.settings.manage.

Rules

A rule names what to catch, where to look for it, and what to do when it is found.

• A new rule is checked at all four checkpoints — except a prompt attack, which is checked in tool results and documents only, because the same instruction is harmless in the person’s own message.
• A topic carries a definition and up to five example phrases.

Checkpoints

Each checkpoint sees text at the moment it enters the conversation.

What is not checked again as a tool result:

• Knowledge search, document reads and attachment search — they return sections already checked at ingest.
• The workspace — it holds files the agent wrote itself.

A document keeps the result it was indexed with. Changing a rule does not re-check indexed documents; re-processing a document applies the rules in force.

What the person sees

Mask chips. A masked value appears in the chat as a chip naming what it was, such as Bank account number, with a tooltip saying the organisation’s guardrails replaced it before it reached the AI.

• In a message the person sent from the same browser tab, the chip shows and hides the value they typed: the tab keeps what it sent in memory and lines it up against the masked text.
• After a reload, in another tab, or in an answer the model wrote, the chip has nothing to show — no copy of the value exists anywhere.

Findings lines. Every finding is listed under the message it was found in: what a rule found in the person’s message sits under the question that opened the turn; what it found in a tool result or the answer sits under the turn’s last answer. One line per action and checkpoint names the subjects:

• Flagged — a flag changes nothing; its tooltip says the finding was recorded for review.
• Masked before the AI read it
• Masked in the answer
• Masked in a tool result
• Tool result withheld

Also:

• Findings in a message written into a running turn are filed under the turn’s question.
• A reload shows the same lines, because the transcript reads them back from the stored findings.
• An engine that failed is not a finding.
• A blocked message or answer gets no line. The turn ends on a card instead, drawn apart from an ordinary failure, naming what the rule blocked and what to do next.

How answers are checked

When every rule at the answers checkpoint only flags, the answer streams as usual and each finished block is checked afterwards.

When a rule there may block or mask, the answer is held back and released one check at a time:

• Each check takes every sentence finished so far, up to a set window of characters — so text reaches the screen one sentence behind the model.
• Sentences that finish while a check is out go into the next one, so a slower engine simply checks less often.
• Text with no sentence end — such as a line closing on a colon before a tool call — is checked and released as soon as anything other than text arrives, so it always appears before the tool row that follows it.
• A sentence end is a full stop, question mark, exclamation mark or ellipsis followed by white space, or a blank line. A single line break is not one, because it can separate a label such as Số tài khoản: from its number.
• None of the identifiers a rule masks contains a sentence end, so a value is never split between two checks.

Engines

Each engine reports what it found; your organisation’s rules choose the action. The strongest action among the findings wins: block over mask over flag.

Pattern engine

Detects, at no cost:

• email addresses
• Vietnamese mobile numbers
• citizen ID numbers (CCCD)
• tax codes — only with a keyword or a branch suffix, because a bare ten-digit number reads as a phone number
• payment card numbers that pass the Luhn check
• bank account numbers that follow a keyword such as STK or số tài khoản

Bedrock engine

Covers topics, harmful content, prompt attacks and the personal data BedrockAmazon BedrockAmazon BedrockAWS's model service, running in your account's region. The portal's models and embeddings come from here, always through LiteLLM.Open in glossary recognises: names, addresses, ages, passwords, usernames, IP addresses, web addresses, card numbers, IBANs and SWIFT codes. It runs in your organisation’s AWS region. Bedrock reports a personal-data value by its text, so every occurrence of that text in the checked passage is masked.

Every Bedrock filter runs in detect mode: Bedrock reports what it found and the portal’s rules decide what happens.

Running both engines

• Every check runs the pattern engine.
• With Bedrock off, no check calls Bedrock and nothing is billed. Rules only Bedrock can check are kept and skipped, and a rule for a Bedrock subject cannot be added.
• Switching Bedrock on publishes your organisation’s Bedrock guardrail before the next check. Until its first version is published, the Bedrock engine checks nothing and the pattern engine runs alone.
• With both running, the strongest action of either engine’s findings wins.
• A sync with Bedrock that fails keeps the reason on the policy; the Guardrails page shows it with a retry.

Standard and Classic tiers

In regions starting us-, eu- and ap-, the guardrail uses Bedrock’s Standard tier through the matching cross-region profile, such as apac.guardrail.v1:0. Other regions fall back to the Classic tier, which reads only English, French and Spanish.

In testing, the Standard tier detected a salary topic, hate, violence, a prompt attack and a person’s name in Vietnamese phrases, and flagged neither of two ordinary questions.

AWS permissions

The role attached to the backend needs these grants, with <account-id> replaced by the deployment’s account:

{
  "Sid": "BedrockGuardrails",
  "Effect": "Allow",
  "Action": [
    "bedrock:CreateGuardrail",
    "bedrock:UpdateGuardrail",
    "bedrock:GetGuardrail",
    "bedrock:CreateGuardrailVersion",
    "bedrock:DeleteGuardrail",
    "bedrock:ApplyGuardrail"
  ],
  "Resource": [
    "arn:aws:bedrock:*:<account-id>:guardrail/*",
    "arn:aws:bedrock:*:<account-id>:guardrail-profile/*"
  ]
}

Cost

A Bedrock check is priced from the text units it reports, at AWS list prices:

Each check that cost anything is added to a daily charge for the person and the department the check ran for — whether or not it found anything.

When a check fails

A check that cannot run is retried once. What happens next is your policy’s choice:

• Blocked (the default) refuses the text. A refused message or answer fails its turn, and a refused document section fails the ingest — which runs again rather than landing a document with nothing indexed.
• Allowed lets the text through and records the failure.

Records of findings

Every finding a rule matched writes one record, and every failed check writes one more. A record names:

• the organisation, department and person
• the checkpoint, kind, subject, action and engine
• what was checked: the turn, the tool call or the document

It never holds the text that matched, and records are append-only. The Guardrails tab of the audit log lists them. A message refused before its turn opened also leaves a model-call record with the admission BLOCKED_GUARDRAIL — see Audit and cost tracking.

Why it works this way

Under the hood

Related

Set up guardrails Switch the policy on, add rules and choose the failure behaviour. Audit and cost tracking What is recorded for every model call and how cost rolls up. Budgets and policy How budget alerts and the hard stop work. Audit log Read guardrail findings on the Guardrails tab.