Policy blocking rules

What they are

A rule is a set of clauses over eight signals: user agent, source IP, X-Forwarded-For chain, endpoint path, HTTP method, a named header, the token prefix, and the model name. Clauses combine with AND or OR, and any clause can be negated to build an allowlist.

Rules are evaluated on ingress, before grants and quotas, so a blocked request never reaches a provider and never costs anything. They apply to the Decisions API too, and to Janus Chat: Chat’s requests carry the browser’s address, its X-Forwarded-For (from trusted proxies only) and its headers.

Give each rule a Reason shown to the caller: a blocked caller receives it in the error response. Without one, the error names the rule and the condition that matched. The list shows how many requests each rule has blocked and when it last fired.

What they are not

Apart from the token and the source IP (the connecting address, or the forwarded address when the connection comes from a trusted proxy in JANUS_TRUSTED_PROXIES), every signal is supplied by the client and can be forged. The X-Forwarded-For chain condition reads the header only when the connection comes from a trusted proxy (JANUS_TRUSTED_PROXIES); a client talking to Janus directly cannot set it, and without trusted proxies the condition never matches. The proxy itself adds to whatever the client sent, so match the addresses your proxy appends. A rule that blocks a user agent stops a tool that identifies itself honestly; it does not stop someone who changes the string.

Use rules to keep sanctioned tooling on the rails. Do not treat them as a containment boundary.

Test before you ship

Administration → Safety & Security → Policy rules → Test a request: fill in a sample user agent, source IP, path, method, model and token prefix, and see which saved rule and which condition would fire, before any real traffic is affected. Header and X-Forwarded-For conditions can only be tested through POST /api/v1/admin/rules/blocking/test.