Skip to main content
Guardrails scan AI request content for sensitive information before it reaches a model provider. An organization admin chooses which scanners run and whether each scanner only reports findings or replaces sensitive values before forwarding the request.
Configure guardrails in the Requesty Console.

​
Plan availability and pricing

Guardrails are available to every organization. They are not restricted to the Enterprise plan.
Guardrails use usage-based pricing. The Console shows the current price beside each scanner and action before you enable it. Prices are per million input tokens for each enabled scanner, and charges from multiple scanners are added together.
Disabled scanners have no charge. Some scanner/action combinations may also be free; use the price displayed in the Console as the current price. Guardrail charges are included in request cost and appear separately from model cost in Logs. Each scanner that ran is listed with its individual charge and any discount.

​
Available scanners

Each scanner is configured independently: Fast scanners favor lower latency. ML scanners use model-based detection for higher accuracy and may add more latency. You can enable more than one scanner when their coverage is useful, but each enabled scanner runs and is priced separately on standard plans.
Earlier scanners (pii, pci, banking, financial, secrets, and secrets/v2/balanced) are not offered to new organizations. Existing configurations stay visible and continue to work.

​
Configure guardrails

You must be an organization admin to change guardrails. The same steps apply on standard and Enterprise plans:
1

Open Guardrails

In the Requesty Console, go to Admin Panel → Guardrails.
2

Review the price

Find the scanner under PII detection or Secrets detection. The price shown beneath its action selector is the charge for that scanner and action. Standard-plan prices are per million input tokens; Enterprise organizations see the included discount.
3

Choose an action

Set the scanner to Disabled, Report, or Mask. The change is saved immediately and applies organization-wide to all API keys.
4

Validate the rollout

Start with Report to measure matches without changing traffic. Review violations in Logs and Compliance, then move to Mask when you are comfortable with the results.
There is no restart or API-key update. Changing a policy creates an audit-log event and affects subsequent traffic.

​
Actions

​
How Mask works

Mask replaces detected sensitive content with a synthetic equivalent before sending it to the model. Requesty keeps the mapping long enough to restore the original value in the response, so an email address or credential does not need to be exposed to the provider just to remain useful to the caller.
Synthetic replacement can affect results when the model must interpret, calculate from, or derive information from the original value. Test representative traffic before enabling Mask broadly, and review false positives regularly.

​
Request and response flow

Guardrails do not scan the model’s response for new sensitive data. The response step restores synthetic values that correspond to masked request content. Guardrails are organization-wide and provider-agnostic, applying consistently across the organization’s API keys and supported models with no per-key bypass.

​
Scan outcomes

Every request records a guardrail verdict with its normal telemetry: When several scanners run, one mask is enough to make the overall verdict Masked. The Compliance page aggregates scan coverage, Flagged and Masked outcomes, and violations by data class for the selected period. Verdict counts use provider attempts, while violation counts use user requests.

​
What the scanners detect

PII scanners detect personally identifiable information such as email addresses, phone numbers, names, government identifiers, and similar personal data.

​
Operational guidance

  • Begin with Report on representative traffic to understand detection coverage and false positives.
  • Compare Fast and ML variants against the accuracy and latency requirements of your workload.
  • Remember that enabling multiple scanners adds both their processing and, on standard plans, their charges.
  • Review guardrail violations in Logs and scan coverage in Compliance.
  • Revisit policy choices when your data flows or compliance requirements change.
Guardrails help enforce a data-handling policy and produce evidence, but enabling a scanner does not by itself certify compliance with GDPR, PCI DSS, SOC 2, or another framework.
  • Compliance for scan coverage and evidence downloads
  • Logs for request-level violations and guardrail cost
  • Data Privacy for Requesty and provider retention controls
  • Approved Models for limiting which models the organization can use
Last modified on August 27, 2026