Policies and detection

Policies decide what Orthalon should do when a protected environment detects sensitive content or an application with a particular sanction state.

Plan requirement: Monitor evaluates built-in detection in Monitor mode. Protect adds policy authoring, active enforcement, templates, testing, and approvals. Business adds configurable content analysis, match exclusions, and supported PDF, Office, spreadsheet, and ZIP inspection.

Understand decisions

A policy in Monitor mode records what its decision would have been but does not alter the action. A policy in Active mode applies the decision when the organization plan permits it.

Create a policy

1. Open Controls → Policies.
2. Start from a template or create a policy.
3. Choose Monitor mode for a new rule.
4. Add conditions such as application, sanction state, detector type, or risk. Where the adapter supplies identity context, you can also target personal, corporate, or unknown AI accounts and approved corporate domains.
5. Select the decision.
6. Place specific, high-priority rules above general rules.
7. Save and wait for a new compiled policy bundle version.
8. Verify a pilot sensor receives that version.

Rules are evaluated deterministically by priority and order. A broad rule above a narrow rule can hide the narrow rule, so use the policy tester before reordering production policies.

Configure identity-aware conditions

Identity conditions are useful only when the enforcement point has an authoritative value. Configure the source of that value before activating a rule:

Desktop and gateway traffic can enforce application-domain and detector conditions when the client is routed through those services. Browser account conditions require managed browser context. MCP stdio policy uses the wrapped server and tool identity; remote HTTP/SSE MCP connections are inventory-only. If required context is missing or UNKNOWN, a narrower identity condition does not match. Add an explicit rule for unknown context when the organization wants to coach or block it.

Use a separate expiring sensor credential for each user, device, or calling service accountability unit. Shared credentials erase the identity boundary that role-based rules and approval records depend on.

Removing a member through organization administration or SCIM permanently revokes that member's organization sensor keys, expires pending and approved grants, removes organization team assignments, and clears the organization from their active sessions. Re-adding the same user requires newly issued keys and new approvals; old credentials are never reactivated.

Test without sending sample text

The policy tester runs detection in the browser. Use invented data and verify:

• which detectors matched;
• which policy and rule won;
• the resulting decision;
• the placeholder-redacted result.

Set every condition used by the rule in the tester: application domain, sanction state, account type, account domain, and member role. Run at least one matching and one near-miss case for each populated condition. A passing local test proves deterministic matching; it does not prove that an endpoint supplies the same identity context. Confirm that separately with a pilot sensor in Monitor mode.

Do not paste real secrets into the tester even though it runs locally.

Configure content analysis

Business and Enterprise administrators can open Controls → Content analysis to choose built-in sensitive-data matchers and tune false-positive exclusions.

Country-specific identifiers currently include:

Labels are required for compact country-number formats that could otherwise be an invoice, ticket, or order number. A valid checksum proves only that a value has the identifier's structure; it does not prove that a person or patient exists. Test both matches and near misses before enforcing a new class.

1. Name the content analysis rule and choose detector classes.
2. Expand a data-type row and add required or forbidden context terms when a match is meaningful only near particular language. Email, credentials, personal data, health data, financial identifiers, source code, internal network addresses, and legal data have independent controls.
3. Add value prefix, contains, or suffix exclusions. Put one value per line; an exception affects only the data-type row where it is configured.
4. Under Email addresses, add internal corporate domains to ignore. customerdomain.com also covers its subdomains while external addresses continue to match.
5. Enable IPv4 addresses, then add protected company IPv4 addresses or CIDR ranges such as 10.42.0.0/16. Only addresses in those ranges match.
6. Add bounded company-specific patterns for internal project identifiers, repository namespaces, hostnames, or proprietary source markers. Pattern matches can have their own required and forbidden context.
7. Choose file formats, the maximum file size (up to 500 MB), and whether ZIP contents should be inspected.
8. Save, sync a pilot sensor, and verify near-matches in Monitor mode before active enforcement.

Small readable text is scanned locally. Supported PDF, Word, PowerPoint, Excel, and ZIP files that need extraction use Orthalon's private short-lived file analysis flow. Raw objects are deleted after analysis and telemetry retains only hashed findings and file metadata. The private quarantine path binds processing to the uploaded R2 object version, rejects active/embedded Office and PDF content plus dangerous archives, and uses the operator's private malware scanner before document parsing. File DLP is not a replacement for endpoint antivirus and quarantined objects are never offered as downloads.

Configure approvals

Protect and higher plans can use Require approval. A request contains the application, detector types, time, and a system-generated surface explanation, not a free-form user field or the protected payload. Administrators decide requests under Controls → Approval requests. Authorized reviewers also see a pending count in the organization navigation and a notification bell on Security overview. New requests appear there in real time when the organization's Ably integration is available; selecting a request opens the matching approval record. The queue remains authoritative and reconciles periodically if realtime delivery is interrupted.

An approval can grant one use, a bounded number of uses, or access until an explicit expiry. Every decision and consumption is audited. For browser enforcement, the request is bound to the organization, requester, browser key, application domain, detector set, account context, and content source. The extension holds the prompt in memory. When Ably is configured, an organization-scoped decision notification wakes the extension, which then fetches the authoritative request status once. A bounded two-minute fallback check covers browser suspension, network loss, and missed notifications. The extension compares the current composer with the exact held state and sends the same randomized 64-hex binding digest at creation and consumption. The digest is SHA-256 over a fresh random nonce and the locally derived salted content fingerprint. The server consumes one use only when that opaque binding and all other conditions match. An edit after request creation stops release. The server never receives raw prompt content, the nonce, or a deterministic prompt fingerprint.

An approval is not a permanent global allow rule. Use a policy change for long-lived access. File approval also requires a completed DLP scan. The browser fingerprints local file bytes in memory. Remote analysis returns a separately randomized per-job byte binding rather than a reusable file hash. The browser combines all selected files into one fingerprint that remains local. It creates a nonce-randomized opaque approval binding, retains the original immutable file references, rejects replacement or reordering, and recomputes the local selection fingerprint before consumption. The server requires the original opaque binding and all other approval conditions before it consumes a use.

Before approving, the reviewer must verify the requester, enforcement surface, application domain, detectors, account context, model or MCP tool restriction, pending expiry, requested use count, and fixed expiry. Use the smallest use count and shortest expiry that completes the task. A grant is never portable to another organization, user, sensor, application, detector set, account context, content source, model, tool, or changed payload. Simultaneous retries must consume the bounded allowance atomically.

When the approval service is unavailable, protected traffic remains held or is denied; it must not fail open. Denial, expiry, sensor-key revocation, plan downgrade, and policy replacement must produce a clear user outcome and must not release the protected action.