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

# Customise What Shadow AI Detects

> Tune the built-in checks, warn instead of block, add your own rules, describe a rule in plain English, and silence one false positive. Lightest change first.

> [!NOTE]
>
> **Five levers, lightest first.** Most changes are the first or second one. Reach for
> a custom rule or a plain-English policy only when the built-in checks can't express
> what you want. Every change applies within about a minute; see
> [When a policy change takes effect](/security/policy-changes).

## Where you make the change

Shadow AI's checks belong to your organization's **Shadow AI Fleet** project: every
enrolled device scans against it. Open it in the dashboard under **Projects**.

**Managing clients as an MSP?** Choose **Act as** for the client on the **Clients**
page first. Each client has its own Shadow AI Fleet project, so a change you make applies
to that client only.

Before you change anything, it helps to know which part of a request each check
reads. The person's newest message is checked in full. The AI app's own instructions
are checked for secrets only, and its tool definitions once each as a manifest. See
[What Shadow AI scans](/shadow-ai/what-is-scanned).

## 1. Turn a built-in check up, down or off

The built-in checks (prompt injection, PII, secrets, toxicity, URLs and the rest) are
tuned, not edited. For each one you can:

* switch it on or off;
* set how strict it is;
* choose which kinds of PII it looks for.

Start from a strictness level (**Strict**, **Moderate** or **Permissive**), then tune
single checks. Both are on the project's **Security Rules** page, under
**Built-in Detectors**. See
[Strictness levels](/security/policy-presets#strictness-levels) and
[Granular guardrail configuration](/security/policy-presets#granular-guardrail-configuration).

## 2. Warn instead of block

To see what a check would catch before letting it block, give it two thresholds:

* a score above the **block** threshold blocks;
* a score between the two **flags**: the prompt goes through, and the event is
  recorded as flagged, with its reason, in the dashboard and your alerts.

This works for **Prompt Injection** and **Toxicity**. See
[Warn and block thresholds](/api-reference/guard#warn-and-block-thresholds).

## 3. Add a rule of your own

A **custom rule** matches a condition you choose, such as a list of words, an email
address or a card number, and takes one of four actions:

* **block**: stop the prompt;
* **redact**: send it with the match masked;
* **flag**: send it, and record and alert on it;
* **allow**: let it through, for allowlist rules.

For example, a rule can flag any prompt that names a client codename. The conditions
and actions are in [Custom rules](/security/custom-rules#rule-conditions).

## 4. Describe it in plain English

When a rule can't capture the boundary ("don't discuss our pricing", "nothing about
unreleased products"), create an **LLM guard** or a **topic filter** policy and
write the rule as a sentence. An AI judge reads every prompt against your sentence.
When it finds a match the policy blocks, or flags if you set the action to `flag`.
See [LLM Guard](/security/custom-rules#llm-guard) and
[Topic filter](/security/custom-rules#topic-filter).

> [!NOTE]
>
> A judged policy reads every prompt, so it adds time and cost to each scan that a
> condition rule does not. Use a condition rule when one will do.

## 5. Silence one false positive

When a check fires on something it shouldn't, open the event and create a
**Suppression**. It stops that one rule deciding for this project, optionally only for
that exact text, until it expires. The ML injection classifier and the secret
detectors can't be suppressed. See [Suppressions](/api-reference/guard#suppressions).

## Who can change policies

By default, any member of the organization can create, edit or delete policies. To
limit that to admins, turn on **Only admins can edit policies** on the **Policy
editing** card under **Settings → Security**. Everyone can still see the policies. For an MSP, turn it on in each client's organization, so
client staff can see the policies you set but can't change them.

## Managing policies as code

To keep policies in version control, or to apply the same set to many clients, see
[Policy-as-Code](/security/policy-as-code).


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