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

# Guardrails

> Define conversation boundaries and review guardrail configuration while dashboard enforcement controls remain in preview.

Guardrails describe topics or behaviors that need a defined response. Start by writing what the agent may help with, when it should ask for clarification, and when it should stop or direct the user elsewhere.

<Note>
  The dashboard's **Guardrails** page is a preview: changes there are not published. The API includes guardrail authoring fields, but saved settings do not establish live moderation, prompt-injection protection, or automated intervention.
</Note>

## Write the policy first

For each boundary, keep a realistic example, the expected response, and the service responsible for enforcing any access restriction. For example, a support agent can explain the account-recovery process while the account service verifies identity before changing a login method.

Do not rely on a prompt or guardrail setting to grant or deny access to private data. [Tool authorization](/agents-platform/configure/tools/overview) must be enforced by the service that owns the action.

## Review the authored settings

Guardrail configuration lives under `platform_settings.guardrails`. The current version discriminator is `version: "1"`.

| Setting | Configuration to review |
| - | - |
| `focus` | Whether the authored focus guardrail is enabled. |
| `prompt_injection` | Whether the authored prompt-injection guardrail is enabled. |
| `content` | Category configuration, execution mode, and trigger action. |
| `moderation` | Optional moderation configuration. |
| `custom` | Optional custom guardrail configuration. |

Content categories include sexual content, violence, harassment, self-harm, profanity, religion or politics, and medical or legal information. Category entries contain `is_enabled` and `threshold`. A stored threshold is a configuration value, not a measured accuracy or protection guarantee.

## Prepare a review

<Steps>
  <Step title="Choose relevant boundaries">
    Select categories that matter for the task. Include ordinary requests that must remain answerable, so the review covers both inappropriate responses and unnecessary refusals.
  </Step>

  <Step title="Save API-authored configuration separately">
    If preparing guardrail fields through the API, preserve the complete agent snapshot and use a [server draft](/agents-platform/deploy/versioning). Read the draft back. Do not treat changes in the preview dashboard as a saved policy.
  </Step>

  <Step title="Record the expected response">
    For each example, specify acceptable wording, any handoff, and whether an external action must be denied. Keep execution verification pending until the applicable runtime path is available.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does enabling a guardrail prove it is enforced?" id="faq-guardrails-enforcement">
    No. Saving a field and verifying runtime enforcement are separate checks. Do not describe the agent as protected against a class of attacks based only on its configuration.
  </Accordion>

  <Accordion title="Why did my dashboard changes disappear?" id="faq-guardrails-preview">
    The Guardrails page is labelled as an unpublished preview. Use the API draft workflow for configuration authoring, and inspect the returned document.
  </Accordion>
</AccordionGroup>


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