Skip to main content

Project-level policies

Without project-level policies, you'd reconfigure the same set of guardrails on every agent — same PII rules, same competitor list, same toxicity threshold. A named Guardrails configuration at the project level lets you do it once and apply it everywhere.

What a named Guardrails config is​

A named Guardrails configuration is a reusable bundle that contains one or more guardrails (PII Detect, Competitor Check, Toxic Language, etc.) — each with its own field selection (Input / Output), parameter values, and corrective action.

Once created, the named config is available to every agent in the project.

Two ways to create a named config​

1. From Project Settings​

  • Open the project-level Guardrails section in Project Settings.
  • Create a new named config (give it a meaningful name like "Customer-facing default" or "Internal QA").
  • Add one or more existing agent guardrail configurations into it.

2. From an Agent​

  • Open an Agent that already has the right set of guardrails configured.
  • Click a Save / Name as project-level config button in the Guardrails section.
  • Give the configuration a name. The current agent's full guardrail setup — guardrails included, their thresholds, corrective actions, field selections — is captured into a new named config.

The second flow is the common one: you tune guardrails on a single agent until they work, then save the result as the project's standard policy.

Applying a named config to an agent​

When setting up guardrails for an agent:

  • Open the Guardrails section of the agent's configuration.
  • Select an existing named Guardrails config from the picker.

That's it. All guardrails in the config — with their current settings (thresholds, corrective actions, input/output field selections) — are instantly applied to the agent. You don't have to recreate any of it.

What gets applied (and what stays linked)​

When you apply a named config to an agent, the agent's guardrail section is populated from the config. From there:

  • The agent uses the current values in the named config at run time.
  • If the named config is later updated, agents that use it pick up the changes on the next run.

This is what makes named configs useful for fleet-wide policy updates — change PII rules in one place and all agents in the project follow.

When to use multiple named configs​

Most projects benefit from a small set of named configs rather than one mega-config:

  • Customer-facing default — full PII detection (FIX), strict toxicity (Exception), competitor check (FIX).
  • Internal QA — relaxed PII (NOOP), looser toxicity (NOOP), no competitor check.
  • Compliance-sensitive (legal, financial) — strict PII (Exception), bias check (Exception), logic check (Exception).

Each agent picks the config that matches its context.

Audit logging​

Creating, editing, deleting, or applying a named Guardrails config is captured in the Audit log under the Settings / project-level resource type.