On this page
01
What you'll set up
Provider scans call an outside service, so they add a small cost and a little time, and like any outside service they can fail. This guide shows you how to keep scans lean, choose what happens when one cannot run, and keep an eye on it.
- Local rules that stop a request before a scan is needed
- A choice for when the scan cannot run
- A view of every request that continued without its scan
- An alert on requests whose scan could not run
You need a guardrail profile with a provider scan, from the previous guide.
02
How a scan decision is made
Local rules always run first, inside the gateway. The provider scan runs only when they let the request through.
1Local rules
No network call
2Provider scan
Only if no local rule blocked
3The model
4Response check
Before your user sees it
A request that a local rule blocks never pays for a provider scan. Put the patterns you know in local rules, and leave meaning-aware checks to the provider.
03
Choose what happens when a scan cannot run
A provider can time out, reject a call, or lose its credential. In the profile's content safety section, If the scan can't run decides what the request does then.
| If the scan can't run | What happens | Use it when |
|---|---|---|
| Continue on local rules (default) | The request goes on with your local rules and shows as Not checked | Availability matters most, and your local rules cover what must never leave |
| Block the request | The request is refused until the scan can run again | An unchecked answer costs more than a paused one |
- Content safety
- On
- Implementation
- Azure AI Content Safety
- If the scan can't run
- Continue on local rules
A request that continues is listed as Not checked in Audit.
04
See what was not checked
A request that continued because its scan could not run is never invisible.
- 1
Open Audit
In Policy violations, filter to Not checked. Requests are grouped by cause, policy, and app, and each cause comes with its fix.
- 2
Watch the dashboard
While scans are not running, Needs attention shows one item per cause for requests that continued, and one for requests a profile set to Block refused. Each clears itself once scans run again.
- 3
Set an alert
Create an alert rule on requests not checked per hour through the API, the CLI, or the MCP server, with your own threshold. It counts every request whose scan could not run, continued or blocked, so your team hears about it first.
05
What each situation does
This table covers a policy that has a provider scan, under each choice.
| Situation | Continue on local rules | Block the request |
|---|---|---|
| Provider times out or errors | Continues, shown as Not checked | Blocked |
| Provider credential missing or revoked | Continues, shown as Not checked | Blocked |
| Cloptima-managed scan cannot be funded | Continues, shown as Not checked | Blocked |
| A local rule blocks first | Blocked by the rule, with no scan | Blocked by the rule, with no scan |
06
A good starting setup
If you are unsure, this order works for most teams.
- 1
Use local rules for credentials and your formats
They are free and instant.
- 2
Add one provider scan
Keep Continue on local rules, so traffic keeps flowing while you learn.
- 3
Watch Not checked for a week
See how often the scan cannot run, and why.
- 4
Choose Block where it matters
Use it for the apps where an unchecked answer is worse than a paused one.
- 5
Keep the scan healthy
Rotate its credential before it expires, and keep AI credits funded for Cloptima-managed scans.
07
If something goes wrong
Most surprises are a provider or a credential.
| What you see | Likely cause | Fix |
|---|---|---|
| Requests show as Not checked | The provider timed out or failed, or its credential is unusable | Follow the fix Audit shows for the cause. Requests keep flowing on your local rules meanwhile |
| Requests are refused while the provider is down | The profile is set to Block the request | Fix the provider, or switch the profile to Continue on local rules |