Security and masking settings

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.

IAM.Secure separates detection, policy action, replacement and event delivery. These mechanisms have independent settings. Changes require the appropriate tenant-scoped role; edition gates can further restrict availability.

Enable and disable controls

There is no universal customer-facing “disable all traffic analysis” switch on these pages. For observation without blocking use flag in a narrow scope and check other active policies; a stricter policy still wins. This changes the response action, not detection.

Create, activate, pause and configure a policy

1. Policies → New policy: unique ID, name, owner, description, Draft status.
2. Set a specific target tenant, not *. The hosted release rejects non-empty scope.apps and scope.groups with HTTP 422 because these boundaries are unsupported. Use a separate tenant for isolation.
3. Add rule → Condition type → Condition value → Action. Add a note and move specific rules above general rules.
4. Use JSON for compound conditions, point and canonical actions. Save, read back and test synthetic text.
5. Activate only after checking. Pause stops this policy; confirm the resulting audit decision.

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.

Some form versions emit blocked/masked/rerouted/flagged/allowed, while the gateway validator accepts block/mask/reroute/flag/allow. On 422 use canonical JSON values; a rejected form is not a saved policy. The simple form models one condition per rule. Keep compound conditions and point in JSON to avoid losing them during conversion.

Conflict resolution

First match wins within one policy. Across matching active policies, the strictest action wins: allow < flag < mask < reroute < block. Conditions in one when must all match. With available inspection and no matching rule the result is allow; ensure scope coverage. Inspection failure always blocks, including when on-prem is available: an uninspected request is dispatched to neither upstream. After successful inspection, an unreplaceable mask escalates to reroute if on-prem exists, otherwise block.

Validate a text attachment in your integration

API calls require your tenant’s inference key; audit viewing and original disclosure require separate administrative permissions. Submit a text file using OpenAI file.file_data / input_file.file_data or SDK document.source with type=base64 and media_type=text/plain. Text MIME types, JSON, XML, JavaScript and YAML are supported. For raw base64 file_data, provide a filename with a supported extension. This is an integration contract; it does not add an upload button to the console.

{"messages":[{"role":"user","content":[{"type":"file","file":{"filename":"example.txt","file_data":"data:text/plain;base64,aGVsbG8="}}]}],"point":"attachment","context":"chat"}

1. Submit this synthetic object to staging /v1/inspect with your inference key. The file content hello is decoded before classification; active policies determine the final action.
2. Repeat with synthetic private data and an injection inside the file. Check decision, verdict.point and Request ID in Audit and forensics. Inspect evaluates a decision without generating a provider response.
3. Allowed /v1/chat/completions calls retain original encoded bytes when forwarding to the provider. A streaming response containing a data URL/JSON is held until complete inspection; ordinary text still uses windows.
4. Invalid encoding, exhausted limits, unsupported binary files and documents referenced by file_id, file_url / source.url fail closed. Correct the input or provide a supported text export; retrying an unread reference cannot bypass inspection.

Extraction is bounded to 64 MiB of cumulative decoded data and eight nested encoding levels. Held SSE frames are bounded to 96 MiB; exhaustion blocks without partially releasing the attachment. PDF/DOCX extraction, OCR, audio transcription and remote document retrieval are not qualified by this text contract. Preserving SDK media fields during forwarding does not establish inspection of image/audio contents.

Decoded content reports span_basis=extracted_text: spans address the extracted text. Until safe rewriting of the original format is supported, that verdict is not maskable; a masking API request for actual replacement returns an error instead of reporting success with an unchanged secret. Check the block/routing reason in audit. Successful extraction does not by itself promise allow or reversible FPE.

Synthetic example: mask email in request traffic

Use the class ID from your deployed registry/verdict.

{"id":"DOCS-EMAIL","name":"Mask email in support requests","status":"draft","owner":"secops","description":"Educational policy; activate only after scoped checks","scope":{"tenant":"docs-demo","groups":[],"apps":[]},"on_inspection_unavailable":"fail_closed","block_message":"Request blocked by organization policy","rules":[{"id":"INJECTION","when":{"injection_detected":true},"then":"block"},{"id":"EMAIL","when":{"data_class":"pii.email","point":"request"},"then":"mask"}]}

Test synthetic email, clean text and injection using the intended tenant/app/point; also test another tenant, response and tool output. Draft does not execute: use supported simulation or activate only for a staging test tenant. Text inspector reports active policy decisions, not automatically the open draft.

For monitoring without blocking change the targeted rule from block to flag while preserving narrow scope. Flag passes text and records the event; another active block still wins. Check winning policy_id/rule_id. Restore the previous document/version to undo and test again.

Masking

1. Masking → Auto-discovery / Verdict classes.
2. Save → Refresh and verify the returned mode.
3. Test replacement through the actually integrated protected flow, not just the toggle’s appearance.

Enlarge screenshot

1 2 3 4

1. Refresh
2. Auto discovery
3. Verdict classes only
4. Save

Router has an additional floor; do not assume the same administrative contract in standalone Secure. The hosted deployment stores the mode in shared Redis without a TTL and retains it across gateway restarts. settings_backend=redis means shared settings; memory means process-local settings. Redis loss and backup remain separate operator responsibilities.

Custom DLP

1. Check edition availability and admin permissions.
2. Provide JSON with a patterns array: stable id, name, check category, severity and regex/keywords. Mount through IAM_SEC_CUSTOM_DLP_PATH.
3. Custom DLP → Reload, then check loaded pattern count. The page does not edit the file.
4. Test positive and negative synthetic examples; configure a policy using the resulting class ID and verify the final action.
5. Remove/change a detector in the file, reload and check referencing policies. Removing one detector does not disable other DLP classes.

Complete file and matching checks

{"patterns":[{"id":"org.customer_id","name":"Synthetic customer number","check":"dlp","severity":"high","regex":"\\bDOCS-CUST-[0-9]{6}\\b"},{"id":"org.project_name","name":"Synthetic project code","check":"dlp","severity":"medium","keywords":["DOCS-PROJECT-ORION"]}]}

This file contract has no separate type, pattern or sensitivity fields. Policy sensitivity refers to the inspection verdict, not a custom-file field. Current detectors are gateway-wide, not isolated by the top-bar tenant filter. Scope the policy action to a specific tenant and test another tenant; app scope is not enforced in the checked staging.

In Custom DLP → Test, DOCS-CUST-123456 should match org.customer_id; DOCS-CUST-12345 should not. Lowercase docs-project-orion should match; DOCS-PROJECT-OTHER should not. Test returns matched and masked_text, but does not execute every active policy: verify the final protected-request decision separately. A reload_failed / 400 keeps the previous successfully loaded set; fix the file, reload and test again. A not_configured / 404 means the operator has not mounted/configured the path.

Alerts, correlation, webhooks and SIEM

Enlarge screenshot

1 2 3 4

1. Tenant
2. Event
3. Threshold / window / cooldown
4. Save

Configure incident correlation

1. Incidents → Correlator → Configure. If the panel is absent, check API availability; this does not prove analysis is disabled.
2. Preserve the old values, edit and Apply. Cancel discards the unsaved editor.
3. Read the panel again and compare values. Check synthetic tenant events, time window and resulting incident; these thresholds do not select the request’s enforcement action.

Enlarge screenshot

1 2 3 4 5

1. Injection threshold
2. DLP threshold
3. Block rate
4. Window, seconds
5. Apply

API: GET /admin/incidents/correlation-config, then administrative PATCH to the same endpoint; read again. GET returns window as a duration string such as 10m0s, rather than window_seconds.

{"injection_burst":3,"dlp_burst":15,"block_rate_min_reqs":10,"block_rate_threshold":0.5,"window_seconds":600}

These are illustrative source defaults, not verified hosted settings. PATCH updates supplied fields only; it cannot change tick_interval. 422 means invalid range; 503 means unavailable correlator. Runtime changes do not promise restart persistence or propagation to other replicas; re-read the affected instance. Restore previous values to undo and verify the next scan. The correlator reads at most 2000 recent entries in the window, so high-volume results are a sample rather than full organizational totals. Zero does not disable these thresholds; notification rules are separately controlled in Alert Rules.

Connect SIEM

1. Obtain an approved receiver endpoint and format.
2. SIEM → Endpoint URL → Event format → Enable SIEM export → Save.
3. An operator sets receiver authorization through IAM_SEC_SIEM_WEBHOOK_AUTH; the UI never displays it. Do not embed tokens in published URLs.
4. Test delivery sends to the configured receiver; verify both exporter status and receiver event.
5. Disable the switch and save to stop export; verify Disabled status. Inspection and local audit continue.

Operator configuration

Source defaults below are not verified hosted settings. An operator changes them; customers request the value and verify its exposed contract.

All sections · Traffic analysis · 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.

Gateway PostgreSQL access

For self-hosted administrators. Hosted customers do not receive database credentials. Application keys and console operator roles are separate from PostgreSQL identities; use the console above to manage policies.

The gateway role has no SUPERUSER, CREATEROLE, CREATEDB, REPLICATION or BYPASSRLS. Schema changes, DROP/TRUNCATE, disabling triggers, server commands and server-file reads are denied. This does not replace application tenant isolation or make audit storage immutable: normal audit retention deletion remains allowed.

1. Take a consistent backup and restore it into a separate database before restricting permissions. Keep role and authentication recovery details outside public documentation.
2. Install the schema through an administrative identity. Set IAM_DB_SCHEMA_MODE=verify for the serving gateway so startup checks the schema without CREATE/ALTER. Resolve migrations administratively without granting the gateway SUPERUSER.
3. Separate owner, runtime and backup identities. Preserve the existing DSN password; do not replace it with an administrator password. Backups require sequence SELECT, which the serving gateway does not need.
4. Replace gateway replicas sequentially. Confirm every physical connection authenticated as the former privileged role has closed; changing role flags alone does not close existing connections.
5. Test key creation, rotation and revocation; policy saving and Activate → Pause; audit/incidents; saved searches; and backup restoration. Revoke temporary keys and preserve customer tables during testing.

If settings stop saving after an update. Check verify mode, the target database and the specific DML permission named by the error. Key-cache triggers need UPDATE(version, updated_at) on the cache-version table. Original-request retention needs UPDATE(ciphertext, status); history needs INSERT and allocator USAGE. Fix the narrow grant and repeat the staging scenario. Do not enable migrate mode in the restricted serving gateway.