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

# Move to Named Guardrail Policies — v0.179

> From v0.179, each guardrail policy is its own named gateway-guardrails-config instead of one document with a rules[] array.

<Warning>
  **Applicable to:** Users who manage Guardrail policies via GitOps (`tfy apply`) with the old folded `{ type, rules: [...] }` YAML.
</Warning>

## What Is Changing

Starting in **v0.179**, each guardrail policy is a **named** `gateway-guardrails-config` — the same grain as [logging configuration](/docs/ai-gateway/logging-config): one configuration name, one `when` block, and the four hook arrays.

Previously, all rules lived in a **single** document:

```yaml theme={"dark"}
name: guardrails-control          # optional / ignored for storage grain
type: gateway-guardrails-config
rules:
  - id: palo-alto-rule
    when: { ... }
    llm_input_guardrails: [ ... ]
  - id: mcp-test-rule
    when: { ... }
    mcp_tool_pre_invoke_guardrails: [ ... ]
```

Now each former rule is its **own** config (apply separately):

```yaml theme={"dark"}
type: gateway-guardrails-config
name: palo-alto-rule
when: { ... }
llm_input_guardrails: [ ... ]
llm_output_guardrails: [ ... ]
mcp_tool_pre_invoke_guardrails: []
mcp_tool_post_invoke_guardrails: []
```

```yaml theme={"dark"}
type: gateway-guardrails-config
name: mcp-test-rule
when: { ... }
llm_input_guardrails: []
llm_output_guardrails: []
mcp_tool_pre_invoke_guardrails: [ ... ]
mcp_tool_post_invoke_guardrails: [ ... ]
```

## Why This Change

Named configs match how other multi-instance gateway policies work (for example logging). You can create, edit, and delete one policy without rewriting the entire set, and GitOps can own one file per policy.

## What You Need to Do

### GitOps / `tfy apply`

1. For each entry under the old `rules[]` array, create **one YAML file** (or one document) with:
   * `type: gateway-guardrails-config`
   * `name: <old rule id>`
   * top-level `when` and the four `*_guardrails` arrays (not nested under `rules`)
2. Remove the folded parent document that only wraps `rules: [...]`.
3. Apply with `tfy apply` (each named config is an independent resource).
4. Prefer copying YAML from the UI (**Edit as YAML** on a rule) so the shape matches production.

## Changes in YAML Schema

| Before (folded) | After (named) |
| - | - |
| One document, `rules: [{ id, when, ... }]` | One document **per** policy |
| Rule identity = `rules[].id` | Config identity = top-level `name` |
| Hooks nested under each rule | Hooks at top level |

`when`, hook field names (`llm_input_guardrails`, …), and `custom_error_message` are unchanged — only the document grain changes.

***

If you face any issues in the migration, reach out to [**support@truefoundry.com**](mailto:support@truefoundry.com).


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