Skip to content
Documentation menu

Products

Policies and Workflows

Router applies group policies at two checkpoints, before a request leaves the gateway for a model and before a model response is returned to the requester.

Router applies group policies at two checkpoints: before a request leaves the gateway for a model, and before a model response is returned to the requester.

Request and response lifecycle#

  1. Submit a request. An employee, application, or agent submits a request to Router.
  2. Evaluate the outbound policy. The outbound checkpoint evaluates the group's policy and handles the request, including transformation where configured.
  3. Send the processed request. Router sends the processed request to the selected model.
  4. Receive the model response. The referencing model returns a response.
  5. Evaluate the inbound policy. The inbound checkpoint evaluates and handles the response, including restoring previously replaced content where applicable.
  6. Return and record the result. Axora Router returns the result and records the processing trace.

Policy actions#

ActionMeaning
AllowPass the request or response.
ObservePass it while recording evidence and alerts.
TokenizeReplace identified sensitive values with placeholders before forwarding.
BlockReject the request or response.
RouteUse an enterprise-approved internal model instead of an external one.
Require ApprovalPause processing and enter an approval workflow.

Rules apply according to the group's policy and the processing stage. They can consider text, organizational dictionaries, content type, the target model, and region. Local-model analysis can support tasks such as identifying named entities.

Tokenization and restoration#

Here, tokenization means replacing sensitive values with placeholders. It does not mean counting a language model's input or output tokens.

In the documented workflow, Router keeps the mapping between an identified value and its placeholder at the gateway. The external model receives the transformed content, and the inbound checkpoint can restore the values when returning the result.

This mechanism applies to values identified and transformed by the active policy. It is not a guarantee that every sensitive detail in an arbitrary document will be detected. Other text and context still need to be assessed against the organization's data-handling rules.

Example: contract review#

An employee submits a contract containing a name and identity-document number. The group's policy identifies those fields and replaces them with placeholders before forwarding the request.

The model reviews the transformed contract and returns its response with the placeholders preserved. Router uses the gateway-side mapping to restore the identified values in the response returned to the employee.

The administrator can inspect the trace across processing stages. In this example, the original values that were replaced are not sent to the external model.

Example: role-based AI access in a law firm#

A law firm may organize employees by role or project sensitivity. Each group can have its own channels, quotas, and handling rules.

Example groupExample channel accessExample policy
Partners and senior lawyersMultiple approved model channelsReplace client names, matter numbers, and project identifiers; observe remaining traffic.
Lawyers and legal assistantsA subset of approved channelsReplace personal identifiers and account information; block highly sensitive content.
InternsA restricted channelApply stricter rules and a smaller quota.
Sensitive-project teamAn approved internal modelRoute client-confidential material internally.

An organization can use its own client-name dictionaries, project codes, and identifier formats alongside personal-data detection.

Audit and policy refinement#

The audit view provides filtering by time, user, model, and decision status. A trace shows key inputs and outputs so administrators can understand how content was handled.

A team can start by observing a selected workflow, review actual traffic and policy matches, and then introduce more restrictive handling where appropriate. Auditable traces should be treated as potentially sensitive data and managed under the organization's access and retention practices.

For the difference between gateway controls, agent action protection, and adversarial testing, see Our Product System.