Policy engine
Override any rule's behavior for your account, without waiting on a code deploy.
What it's for
The scoring engine ships with a sensible default action for every rule: score it and move on. The policy engine lets you override that default per rule, per account — useful when a specific rule is a known false- positive source for your particular traffic, or when you want a specific signal to be an automatic hard stop regardless of the overall score.
The four actions
| Action | Effect |
|---|---|
default | Unchanged — the rule scores normally. This is every rule's starting state; setting an override to default removes it entirely rather than storing a no-op row. |
allow | The rule is treated as though it never fired at all — no score contribution, not even listed in reasons. |
challenge | If this rule fires, the final decision is escalated to at least SOFT_CHALLENGE — but never used to downgrade a decision the score already earned on its own. |
deny | If this rule fires, the final decision is forced to BLOCK — same escalation-only posture. |
Escalation only, by design
challenge and deny can only push a decision toward BLOCK — they can
never override a strong signal elsewhere into a weaker decision. This is
the same principle that shows up throughout KaizoCore's design: automated
overrides add caution, they never remove it.
Managing overrides
From the dashboard's Rules page: every currently-registered rule is listed (pulled live from the same registry the scoring engine runs against, so it can never drift out of sync), grouped by layer, each with an action dropdown. Changes save immediately — no publish step.
Via the API:
GET /v1/policy/rules # list every rule + your current override
PUT /v1/policy/rules # { "rule_id": "network/vpn_ip", "action": "deny" }A concrete example
Say your product legitimately serves a lot of real users on corporate VPNs,
and network/vpn_ip is generating more SOFT_CHALLENGE friction than it's
worth for your specific traffic. Set it to allow:
{ "rule_id": "network/vpn_ip", "action": "allow" }Every other rule keeps scoring normally — this doesn't turn off VPN-related risk broadly, it specifically stops this one rule from contributing, while everything else (impossible travel, bad-actor registry, behavioral signal) still applies in full.