> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beyondguard.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Policies and Multi-Policy Management
> Define versioned, group-scoped policy sets and assign them per endpoint — so different business units run fully isolated rule sets on the same platform.
A **policy** is the rule set every request is evaluated against on a given endpoint. The **Multi-Policy** module lets you define and manage customized policies for different organizational units, so a change affects only the group it applies to — not the whole organization.
Each policy is classified by a **Policy Type** (for example, Prompt Guard, Agent Guard, or MCP Guard) and scoped to an **Organization**. Create one from the **Create Policy** action.
## Policy configuration
Policies are **versioned**: every change is tracked, versions can be compared, and an earlier version can be restored when needed. Once created, a policy can be:
* **Edited** — update its controls and thresholds.
* **Copied** — used as a template for a new policy.
* **Deleted** — only if it has no usage history. A policy in active use cannot be deleted, to preserve data integrity.
Policies can also be bound to **Policy Groups** — specific user groups within an organization — so a policy forms the rule set for that group, with a visible group-based scope of effect.
## Policy list
The **Policy List** gives a centralized view of every policy in the system. Filter by **Policy Type** and **Organization** to find policies quickly, and act on them directly from each row (**Edit / Copy / Delete**). The **Policy Groups** sub-screen lists, for each group, its organization, the number of users, and the number of associated policies.
## Endpoint assignment
The **Policy Settings** tab is the assignment layer that determines how policies apply on an endpoint or proxy configuration. It has two parts:
* **Group-Based Policies** — assign policies to specific user groups. Each assignment row carries the group name, the associated policy, its version, and status (active/inactive). Rules are evaluated in **priority order** and can be reordered by drag and drop.
* **Public Policy** — the default fallback policy that takes effect when the calling user matches no group. It's toggled on or off, and a **Control Mode** switches between **Basic** and the (in-development) **Advanced** mode.
Once saved to an endpoint, the configuration for the incoming request's user group takes effect automatically — no additional integration or manual step is required.
Because policies are organization- and group-scoped, different business units (for example, Finance and R\&D) can run fully isolated rule sets suited to their own risk tolerance on the same platform.
## Customizable error messages
When a security rule is violated, the message returned to the client can be customized to your brand language, tone, and communication standards instead of the default text — with distinct, user-friendly messages for different scenarios (prompt injection, PII detection, toxic content, and so on).
* A **Log ID** is added to every error response, matched one-to-one with the request's log record for fast, incident-based investigation.
* **BG header**–based differentiation lets the same policy return different, brand-appropriate messages at different integration points.
## Related
Where policies are assigned and enforced.
The individual controls a policy turns on.
Feed discovered usage into a group's policy.
Threshold, allowlist, and enforcement tuning.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.