Controls and policies
Panicly enforcement is layered. Some controls live in the core rules engine, while others are enforced in the broader gateway path.
Immediate project traffic stop before upstream provider spend.
Sender IP blocking and inspection.
Country and Panicly-defined region blocking, backed by geo_rules.
Per-project model enable and disable state backed by model_rules.
Blocks requests that exceed configured token limits.
Detects repeated identical payload patterns.
Evaluation layers
1. Workspace and project auth
The Panicly key must belong to a valid project in the workspace.
2. Plan and quota
Panicly checks included monthly volume and purchased capacity before routing.
3. IP, region, and model controls
The gateway can block by sender IP, country, product-defined region, or disabled model before provider forwarding.
4. Core rules engine
Panicly checks Kill Switch, burst protection, abuse detection, token guard, and loop guard.
5. Upstream provider result
Approved requests can still be rejected by the upstream provider. Panicly should still record the outcome.
Use trusted location signals
Region and network decisions depend on trusted platform or proxy location signals, not arbitrary client-supplied headers.
Rule tuning fields
Per-project burst protection threshold.
Rolling abuse or spend-style threshold.
Maximum token budget accepted for a request.
Sensitivity for repeated-payload detection.