Monitor mode
Every app starts here. Read the projection, understand who you would lock out, and only then enforce.
In monitor mode every request is evaluated exactly as enforcement would evaluate it, the decision is recorded, and nothing is refused. It is the default for every app, and you should stay in it until the numbers below stop surprising you.
The projection
curl "https://api.vouch.dev/v1/apps/app_123/security/projection?from=2026-09-01&to=2026-09-17" \
-H "Authorization: Bearer sk_live_…"| Field | Counts |
|---|---|
blocked_requests | Requests enforcement would have refused. In monitor mode none of them actually were. |
blocked_devices | Distinct devices behind those requests. |
degraded_devices | Of those devices, the ones that looked legitimate but could not be fully checked. |
challenged_requests | Requests that would be sent through a step-up rather than refused. |
by_policy | Which rule would refuse, labelled with its pattern. |
by_reason | Why, taken from the reasons recorded on each decision. |
Read degraded_devices first
This is the number that decides whether enforcing is safe, and it is reported on its own rather than
folded into blocked_devices for exactly that reason.
A device is degraded when Vouch could not fully check it: no Play Integrity credentials, an
unreachable platform API, a de-Googled handset, an older operating system. Those are usually
customers. If a rule requiring min_verdict: pass would block four hundred devices and three
hundred and eighty of them are degraded, you are not about to stop an attack. You are about to stop
your own users from using the app.
A large degraded_devices count almost always means your rule is too strict, or your credentials
are not configured, rather than that you are under attack. Check
attestation credentials before you enforce.
Why you can trust the numbers
The projection is computed from the decisions that were actually recorded, not estimated from verdicts. The headline cannot disagree with the device list or the policy order shown beneath it, because all three are reading the same log.
That also means the projection is only as good as your traffic. A week of real usage tells you something; an hour of your own testing does not.
Switching to enforce
Watch for a full week
Long enough to include your quieter days and at least one app release.
Check what would break
Read degraded_devices and by_reason. If most refusals come from devices that cannot attest
rather than devices that failed, fix the rule or the credentials, not the users.
Loosen the rule until only abuse is caught
min_verdict: degraded blocks only devices the platform actively rejected. It is the usual
first rule to enforce.
Enforce
curl -X PATCH https://api.vouch.dev/v1/apps/app_123/security/settings \
-H "Authorization: Bearer sk_live_…" \
-H "Content-Type: application/json" \
-d '{"mode":"enforce"}'Keep watching the projection. It now reports what is being refused rather than what would be.
Going back is one call with "mode":"monitor", and takes effect immediately.