Skip to main content
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.

​
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.

​
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 and 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.

​
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.

​
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 and Topic filter.
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.

​
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.