> ## Documentation Index
> Fetch the complete documentation index at: https://docs.requesty.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Guardrails

> Configure organization-wide and per-group PII and secret scanning with usage-based pricing or Enterprise inclusion

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.

<Note>
  **[Configure guardrails](https://app.requesty.ai/admin-panel/guardrails)** in the Requesty Console.
</Note>

## Plan availability and pricing

Guardrails are available to **every organization**. They are not restricted to the Enterprise plan.

<Tabs>
  <Tab title="Standard plans">
    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, charged only on prompt tokens that were not served from the provider's prompt cache, and charges from multiple scanners are added together.
  </Tab>

  <Tab title="Enterprise">
    All guardrails are included with the Enterprise plan. The Console shows the standard price crossed out with a 100% Enterprise discount.
  </Tab>
</Tabs>

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](/features/logs). Each scanner that ran is listed with its individual charge and any discount.

## Available scanners

Each scanner is configured independently:

| Scanner | ID | Detects |
| - | - | - |
| PII - Fast | `pii/v2/fast` | Personally identifiable information, optimized for performance |
| PII - ML | `pii/v2/ml` | Personally identifiable information, model-based and optimized for accuracy |
| Secrets - Fast | `secrets/v2/fast` | Credentials and API keys, optimized for performance |
| Secrets - ML | `secrets/v2/ml` | Credentials and API keys, model-based and optimized for accuracy |

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.

<Info>
  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.
</Info>

## Configure guardrails

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

<Steps>
  <Step title="Open Guardrails">
    In the Requesty Console, go to **Admin Panel → Guardrails**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Choose an action">
    Set the scanner to **Disabled**, **Report**, or **Mask**. The change is saved immediately and applies to every API key whose group follows the organization default.
  </Step>

  <Step title="Validate the rollout">
    Start with **Report** to measure matches without changing traffic. Review violations in [Logs](/features/logs) and [Compliance](/features/compliance-report), then move to **Mask** when you are comfortable with the results.
  </Step>
</Steps>

There is no restart or API-key update. Changing a policy creates an audit-log event and affects subsequent traffic.

## Per-group guardrails

By default every group follows the organization's guardrails. To give a group its own setting, open **Admin Panel → Groups** and click the group's **Guardrails** column, then choose one of:

| Mode | Behavior |
| - | - |
| Organization default | The group uses the organization's guardrails, including any future changes |
| Custom | The group uses only the scanners and actions you pick for it |
| Off | Requests from the group are not scanned |

Requests made with a group's API keys use that group's setting. Saving **Custom** with no scanners enabled sets the group to **Off**. Changes take effect on subsequent traffic and are recorded in the audit log.

## Actions

| Action | Behavior | Billing |
| - | - | - |
| Disabled | The scanner does not run | No charge |
| Report | The scanner records violations and forwards content unchanged | Displayed Report price |
| Mask | The scanner replaces detected values before provider processing and restores matching replacements in the response | Displayed Mask price |

### 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.

<Warning>
  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.
</Warning>

## Request and response flow

```mermaid theme={"dark"}
graph TD
    A[API request] --> B[Input scanning]
    B --> C{Violation found?}
    C -->|No| D[Model provider]
    C -->|Report| D
    C -->|Mask| E[Replace sensitive values]
    E --> D
    D --> F[Model response]
    F --> G[Restore matching replacements]
    G --> H[Response to caller]
```

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 provider-agnostic and apply consistently across supported models. Each request uses its group's guardrails, or the organization's guardrails when the group follows the organization default, with no per-key bypass.

## Scan outcomes

Every request records a guardrail verdict with its normal telemetry:

| Verdict | Meaning |
| - | - |
| Passed scanning | Scanning completed and found no violations |
| Flagged | A Report scanner found a violation; content was forwarded unchanged |
| Masked | At least one violation caused content to be replaced |
| Not scanned | No configured guardrail scanned the request |
| Scan error | The request could not be fully evaluated |
| Not recorded | The request predates verdict recording |

When several scanners run, one mask is enough to make the overall verdict **Masked**.

The [Compliance page](/features/compliance-report) 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

<Tabs>
  <Tab title="Personal data">
    PII scanners detect personally identifiable information such as email addresses, phone numbers, names, government identifiers, and similar personal data.
  </Tab>

  <Tab title="Credentials and secrets">
    Secrets scanners detect API keys, tokens, database credentials, service-account keys, and other authentication secrets.
  </Tab>

  <Tab title="Financial data (legacy)">
    Legacy `pci`, `banking`, and `financial` scanners cover payment-card, bank-account, and other financial information. They are available only to organizations that already have them configured.
  </Tab>
</Tabs>

## 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.

## Related features

* [Compliance](/features/compliance-report) for scan coverage and evidence downloads
* [Logs](/features/logs) for request-level violations and guardrail cost
* [Data Privacy](/features/data-privacy) for Requesty and provider retention controls
* [Approved Models](/features/approved-models) for limiting which models the organization can use


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.