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. Stored internally as panic_mode.
Sender IP blocking and inspection, backed by ip_rules or local fallback storage.
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.
The Panicly key must belong to a valid project in the workspace.
Free workspaces stop when included volume is used. Paid workspaces can continue when credit-backed capacity exists.
The gateway can block by sender IP, country, product-defined region, or disabled model before provider forwarding.
The rules engine checks Sentry Mode, burst protection, abuse detection, token guard, and loop guard.
Approved requests can still be rejected by the upstream provider. Panicly should still record the outcome.
Region and network decisions depend on trusted platform headers or trusted proxy sources. Do not document them as trusting arbitrary client-supplied headers.
Per-project burst protection threshold.
Rolling abuse or spend-style threshold.
Maximum token budget accepted for a request.
Sensitivity for repeated-payload detection.