Prepare a tenant protection policy

Role: deployment operator. These steps use the operator console. An ordinary hosted account exposes only its own keys and limits; request policy, protection-mode and masking changes from the operator.

Before you start

You need policy-editing permission and agreed protection rules. Saving a draft is different from enabling enforcement.

Click path

1. Open Политики (/policies) → Новая политика.
2. Enter a unique ID, name, owner and description. Keep Статус: Черновик while reviewing.
3. Set Тенант to the organization. * means all tenants. Non-empty scope.apps and scope.groups are rejected with HTTP 422. Use a separate tenant for isolation.
4. Select the condition type, value and action. An agreed example is sensitivity → RESTRICTED → block.
5. Add rules if needed and review ordering. Open JSON and check the canonical then value (block, not blocked) before Создать политику; the gateway rejects unsupported form values with 422. Keep compound conditions and point in JSON.
6. Open the saved card → Редактировать документ and activate only the agreed configuration.
7. Run a control inspection and inspect Аудит и форензика or the card’s audit link.

Enlarge screenshot

1 2 3 4 5 6

1. Check all predicates
2. Status
3. Tenant
4. true / false
5. Action
6. Save policy

Editor and server released on 15 October 2026. Canonical block, rule IDs and additional predicates survive JSON → Form → JSON. For injection_detected and provider_unlisted, the form displays and accepts true or false; false is no longer shown as RESTRICTED. Check compound predicates, including point, in JSON. Unsupported groups/apps are disabled with an explanation and rejected by the server with 422; use a specific tenant. All replicas read the saved state from shared storage.

Verify and recover

The saved policy must have the intended ID and scope. After activation, a control request must show the expected policy action. A draft does not prove enforcement. For conflicts, compare the current document; do not broaden scope to bypass missing access.

Complete policy fields and JSON compatibility · FAQ

Replica consistency after saving

In the hosted release dated 15 October 2026, policies are saved in shared PostgreSQL. Replicas read the committed overrides on administrative reads and before a new enforcement decision. Save policy, Activate and Pause no longer require a separate manual reload of every replica.

1. Preserve the original JSON, ID and specific tenant. Prepare and qualify changes as a Draft on staging.
2. Save, reread GET /admin/policies/{id}?format=document, and compare scope, status, rule IDs and every predicate. JSON → Form → JSON must retain point and explicit false values.
3. Activate the test policy and send a new /v1/inspect with your customer key. Compare decision.action, policy_id, rule_id and request ID. The operator repeats the document and request checks on every serving replica.
4. Pause excludes only that policy. Other active rules remain, so the result need not become allow. Use Activate to resume.
5. Restore the original document or selected version to roll back, then repeat readback and request checks. A file-backed base policy cannot be deleted through the API; pause it for a temporary exclusion.

A shared-store failure does not acknowledge an unpersisted edit. Inspection blocks when the current authoritative policy set cannot be read. Do not work around storage errors by setting scope to * or weakening rules. Older self-hosted versions may require manual reload; ask the operator to confirm the gateway version first.

Shared staging qualification saved through the operator editor and checked active → block → paused → another active rule → active on both replicas without reload. On a separate isolated staging stand, both replicas were replaced and saved policy/masking state survived.

What was verified on the working stand

• Normal customer SSO, key creation, inventory persistence after reload, a real API request, revocation and HTTP 401 for the old key.
• Customer limit editing, full-reload readback, sign-in suspension and restoration — customer account.
• Test policy save and switching with every-replica controls. Tenant isolation passed; app isolation did not enforce.
• Masking: the shared deployment saves the mode in Redis and rereads it across replicas. A separate real staging stand with owned PostgreSQL/Redis qualified UI saves auto → verdict_classes → auto, persistence after replacing both pods, a synthetic email becoming [CONTACT] at the test receiver, and no receiver call on block. This server mechanism is released in hosted production. This does not qualify every replacement class or guarantee recovery after losing Redis storage itself.

A harmless capital-of-France question returned HTTP 200, CONFIDENTIAL and reroute by another policy on /v1/inspect. This is a false-positive classification, not proof of secret data or successful response generation. Provide the operator with the request ID and a sanitized example; do not weaken global protection to make the test green.