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

# Guardrails Overview

> Platform-configured security policies for AI agents — block PII, redact sensitive data, restrict tool access. Not a code library — configured via Civic UI or Chat

## What are guardrails?

Guardrails are security policies that sit between your AI assistant and the tools it uses. They inspect, validate, and transform requests and responses to ensure your AI operates within safe boundaries.

<Note>
  **Why guardrails matter:** When AI assistants have access to powerful tools, they need constraints that traditional security models don't provide. Guardrails protect against data exposure, accidental destructive actions, and prompt injection attacks.
</Note>

<Frame caption="Add guardrails to tools directly from the Civic UI">
  <img src="https://mintcdn.com/civic/PFVOK2yVrcsVNyC7/images/civic/guardrails-ui.png?fit=max&auto=format&n=PFVOK2yVrcsVNyC7&q=85&s=537eb0e9612808b01205e3bdf280135b" className="image-60 image-rounded" alt="Civic UI showing guardrail options for GitHub tools" width="1140" height="1544" data-path="images/civic/guardrails-ui.png" />
</Frame>

## Managing guardrails

Manage guardrails through the Civic UI when adding tools to your toolkit, or through natural conversation with your AI assistant.

### View available guardrails

Ask your AI assistant:

> "What guardrail templates are available for Gmail?"

> "Show me guardrails I can add for the GitHub search\_code tool"

### Add a guardrail

> "Add a guardrail to block searches containing 'password' and 'secret'"

> "Set up PII redaction for Notion responses"

The AI will find the appropriate template, ask for any required values, and create the guardrail for your toolkit.

### List active guardrails

> "What guardrails are currently active for my GitHub server?"

### Remove a guardrail

> "Remove the guardrail that blocks Gmail searches for passwords"

## Why use guardrails?

AI assistants are powerful but need appropriate constraints:

| Risk                                      | Guardrail solution                                            |
| ----------------------------------------- | ------------------------------------------------------------- |
| AI reads sensitive data it shouldn't      | Request guardrails block access to certain fields or patterns |
| Tool responses contain PII                | Response guardrails automatically redact sensitive data       |
| Prompt injection attempts                 | Built-in detection blocks malicious prompts                   |
| Overwhelming context with large responses | Response processors truncate or transform data                |
| Accidental destructive actions            | Block or require confirmation for write operations            |

### The AI is not a human

When a human reads an email, they understand context and exercise judgment. An AI assistant:

* Will happily read every email in your inbox if asked
* Cannot distinguish between legitimate requests and prompt injection attacks
* May expose sensitive data by including it in responses
* Could execute destructive operations without understanding consequences

### Scale amplifies risk

What takes a human hours to do manually, an AI can do in seconds. A misconfigured tool that exposes one record is an incident. An AI iterating through thousands of records is a breach.

## How guardrails work

Guardrails are evaluated at two points in the tool execution pipeline:

<div style={{display:'flex',flexDirection:'column',alignItems:'center',gap:'8px',padding:'20px 24px',background:'rgba(124,59,237,0.04)',borderRadius:'8px',border:'1px solid rgba(124,59,237,0.15)',margin:'16px 0'}}>
  <div style={{display:'flex',alignItems:'center',gap:'8px'}}>
    <span style={{padding:'8px 16px',borderRadius:'6px',background:'rgba(124,59,237,0.10)',fontSize:'13px',fontWeight:'600',whiteSpace:'nowrap'}}>Request</span>
    <span style={{color:'#7C3BED',fontSize:'16px'}}>→</span>
    <span style={{padding:'8px 16px',borderRadius:'6px',background:'rgba(124,59,237,0.25)',fontSize:'13px',fontWeight:'700',color:'#7C3BED',whiteSpace:'nowrap'}}>Request Guardrails</span>
    <span style={{color:'#7C3BED',fontSize:'16px'}}>→</span>
    <span style={{padding:'8px 16px',borderRadius:'6px',background:'rgba(124,59,237,0.10)',fontSize:'13px',fontWeight:'600',whiteSpace:'nowrap'}}>Tool Execution</span>
  </div>

  <span style={{color:'#7C3BED',fontSize:'20px',lineHeight:'1'}}>↓</span>

  <div style={{display:'flex',alignItems:'center',gap:'8px'}}>
    <span style={{padding:'8px 16px',borderRadius:'6px',background:'rgba(124,59,237,0.25)',fontSize:'13px',fontWeight:'700',color:'#7C3BED',whiteSpace:'nowrap'}}>Response Guardrails</span>
    <span style={{color:'#7C3BED',fontSize:'16px'}}>→</span>
    <span style={{padding:'8px 16px',borderRadius:'6px',background:'rgba(124,59,237,0.10)',fontSize:'13px',fontWeight:'600',whiteSpace:'nowrap'}}>Response</span>
  </div>
</div>

### Request guardrails

Evaluated **before** the tool runs. They can:

* **Block** requests that violate policies
* **Validate** parameters meet requirements
* **Filter** which operations are allowed

### Response guardrails

Evaluated **after** the tool runs. They can:

* **Redact** sensitive information from responses
* **Transform** data (e.g., HTML to Markdown, JSON to CSV)
* **Truncate** overly long responses
* **Remove** specific fields from the output

## Available guardrails

There are 14 guardrails available out of the box, in three categories. All can be scoped to a specific tool, an entire server, or applied globally across all tools in a toolkit.

### Request guardrails

Applied before a tool executes — blocks sensitive data from being sent.

| Guardrail                              | What it blocks                                               |
| -------------------------------------- | ------------------------------------------------------------ |
| **Block PII in Requests**              | SSNs, emails, phone numbers, IPs, passport numbers, and more |
| **Block Credit Cards in Requests**     | Credit card numbers in any format                            |
| **Block SSN in Requests**              | Social Security Numbers specifically                         |
| **Block Prompt Injection in Requests** | Jailbreaks, role overrides, encoded injection payloads       |

### Response guardrails

Applied after a tool executes — redacts sensitive data from responses.

| Guardrail                                  | What it redacts                                   |
| ------------------------------------------ | ------------------------------------------------- |
| **Redact PII from Responses**              | SSNs, emails, phone numbers, IPs, and more        |
| **Redact Credit Card Numbers**             | Credit card numbers from any response             |
| **Redact Email Addresses**                 | Email addresses specifically                      |
| **Redact IP Addresses**                    | IPv4 and IPv6 addresses                           |
| **Redact Phone Numbers**                   | International phone number formats                |
| **Redact Social Security Numbers**         | SSNs specifically                                 |
| **Redact Prompt Injection from Responses** | Injection patterns embedded in tool-returned data |

### Response transforms

Applied after a tool executes — reshapes data to reduce token usage.

| Transform         | What it does                                   |
| ----------------- | ---------------------------------------------- |
| **JSON to CSV**   | Converts JSON arrays to CSV format             |
| **Remove Fields** | Strips specified fields from responses         |
| **Retain Fields** | Keeps only specified fields, discards the rest |

## Guardrail hierarchy

Guardrails operate at three levels, each with different scope:

| Level       | Scope                             | Example use case                           |
| ----------- | --------------------------------- | ------------------------------------------ |
| **Account** | Applies to all users and toolkits | Company-wide PII redaction policy          |
| **Toolkit** | Applies to a specific toolkit     | Production toolkit blocks write operations |
| **User**    | Applies to a specific user        | Individual's custom blocked terms          |

Higher levels cannot be overridden by lower levels. An account-level guardrail blocking access to `/etc/passwd` cannot be bypassed by a user-level guardrail.

## Common guardrail examples

<CardGroup cols={2}>
  <Card title="Block sensitive search terms" icon="ban">
    Prevent the AI from searching for passwords, secrets, or credentials.

    > "Add a guardrail to block searches containing 'password', 'secret', 'api\_key'"
  </Card>

  <Card title="Restrict to specific domains" icon="globe">
    Only allow web fetching from approved domains.

    > "Add a guardrail to only allow fetching from docs.example.com"
  </Card>

  <Card title="Redact PII in responses" icon="user-secret">
    Automatically replace sensitive data with \[REDACTED].

    > "Enable PII redaction for email addresses in all responses"
  </Card>

  <Card title="Block destructive operations" icon="trash">
    Prevent accidental data loss.

    > "Add a guardrail to block the delete\_repository tool on GitHub"
  </Card>
</CardGroup>

## Response processors

In addition to security guardrails, you can add **response processors** that optimize tool outputs for AI consumption. These reduce token usage and improve response quality.

<CardGroup cols={2}>
  <Card title="Retain specific fields" icon="filter">
    Keep only the fields you need, removing unnecessary data.

    > "Add a processor to retain only 'id', 'name', and 'status' from campaign responses"
  </Card>

  <Card title="Convert HTML to Markdown" icon="file-code">
    Transform verbose HTML into compact Markdown.

    > "Convert HTML responses to Markdown for the web scraper"
  </Card>

  <Card title="Remove metadata fields" icon="trash-can">
    Strip internal fields like timestamps and IDs.

    > "Remove 'created\_at', 'updated\_at', and 'internal\_id' from responses"
  </Card>

  <Card title="Truncate long content" icon="scissors">
    Abbreviate overly long text fields.

    > "Truncate description fields to 500 characters"
  </Card>
</CardGroup>

Response processors use the same management interface as guardrails - just ask your AI assistant to add them.

## Troubleshooting

<AccordionGroup>
  <Accordion title="You don't have permission to add guardrails">
    Adding and removing guardrails requires account management permissions. Contact your account administrator or check your role.
  </Accordion>

  <Accordion title="Guardrail not triggering">
    Ensure:

    1. The guardrail is enabled (check with "list active guardrails")
    2. The guardrail is scoped to the correct server and tool
    3. The data matches the expected schema path
  </Accordion>

  <Accordion title="Too many false positives">
    If guardrails are blocking legitimate requests:

    1. Review the guardrail's value/pattern configuration
    2. Consider using a more specific schema path
    3. Remove and re-add with adjusted parameters
  </Accordion>
</AccordionGroup>

## Best practices

Guardrails complement authentication and authorization by controlling *how* tools are used, not just *who* can use them.

<Steps>
  <Step title="Start restrictive">
    Begin with tight controls and loosen as needed. It's easier to relax rules than recover from a breach.
  </Step>

  <Step title="Layer defenses">
    Combine multiple guardrail types for robust protection. Request validation + response redaction provides defense in depth.
  </Step>

  <Step title="Monitor triggers">
    Track when guardrails activate to understand patterns and refine policies.
  </Step>

  <Step title="Document policies">
    Make it clear why each guardrail exists so future team members understand the reasoning.
  </Step>
</Steps>