Skip to main content
The Compliance page puts your organization’s traffic-handling policies and the traffic observed against them in one place. Admins can review or change supported controls, investigate guardrail violations and configuration changes, and download the same information as an evidence report.
Open Compliance in the Requesty Console.

​
Who can use it

Compliance is admin only and covers the whole organization. Members who open the URL directly are redirected to Analytics. See RBAC for the full role breakdown.

​
Current policy and observed traffic

The page separates each control into two columns:
  • Current policy reads the organization’s configuration now.
  • Observed summarizes traffic during the selected reporting period.
Choose Last 7 days, Last 30 days, or Last 90 days. The default is 30 days. Changing the period regenerates the observed figures; it does not change your policies.
Policy settings are live, but observed figures and the downloadable evidence are a point-in-time report. After changing a setting, select Regenerate to include it in the evidence. The page shows a warning while the report snapshot is stale.

​
Requesty controls

These rows describe how traffic is handled inside Requesty’s infrastructure:

​
Requesty zero data retention

Enabling Requesty zero data retention stops Requesty from storing request and response content across every existing and future API key. It overrides content logging configured on individual keys, while usage metadata such as model, token counts, cost, and latency is still recorded. This setting takes effect immediately. After it is enabled, contact [email protected] to turn it off.

​
Allowed Requesty regions

Leave serving regions Unrestricted to allow all current and future Requesty regions, or choose one or more of EU, US, and APAC. A restricted organization must send requests to an allowed regional domain, such as router.eu.requesty.ai; requests through the global domain or a disallowed region are rejected. See EU Routing for endpoint details and the distinction between Requesty’s serving region and a model provider’s hosting location.

​
Model provider controls

These rows describe what happens after Requesty forwards traffic to a model provider:

​
Require zero-data-retention models

When this policy is required, Requesty only routes to models whose providers neither retain request data nor use it for training. A model that does not meet the requirement is rejected even if it is on your approved-model list. This setting takes effect immediately. After it is enabled, contact [email protected] to remove the requirement.
Model hosting locations and data practices are resolved from the model catalog when the report is generated. Traffic for a model that is no longer in the catalog appears as Not recorded.

​
Guardrail violations

The Guardrail violations section shows what sensitive-data scanning found during the selected period:
  • Outcome breakdown counts requests that were Flagged or Masked.
  • Violations by data class groups violations into pii, financial, secrets, and other, split by the action taken.
The JSON artifact also includes matches, the number of individual sensitive values found. The page and PDF show violations, the number of requests that tripped a policy. See Guardrails to configure scanners and understand each action.

​
Configuration changes

This section counts configuration changes and distinct actors during the selected period. Select Audit log to inspect the individual events.

​
How requests are counted

Traffic and guardrail verdict counts are provider requests, not user requests. A user request that falls back across three providers counts up to three times. Requests blocked by Requesty policy before reaching a provider are excluded. Violation counts are per user request.
This counting basis evidences how many provider attempts handled the traffic. It can therefore be higher than counts on Overview and Usage Analytics, which count user requests.

​
Downloading evidence

Select Download PDF for the human-readable report. Use the adjacent dropdown to choose a format:
A formatted document for auditors, customer security teams, or your own records. It includes the policy snapshot, observed traffic, guardrail activity, configuration changes, scope, and limitations. Each page footer carries the payload SHA-256 that identifies the corresponding JSON artifact.Saved as compliance-report-<period>-<date>.pdf.
The report is generated on demand and streamed directly to you. Requesty does not store a report archive. Its configuration snapshot reflects settings at generation time, not the historical settings for every moment in the selected period.

​
Verifying a JSON report

The JSON file contains a payload and its payload_sha256. The hash is the SHA-256 of the compact JSON encoding of payload. To re-derive it:
The result must match payload_sha256 in the downloaded file. Automated consumers should also check payload.schema_version; it is incremented when the artifact shape changes incompatibly. Default-valued fields may be omitted, so treat a missing boolean as false, a missing count as 0, and a missing list as empty.
This hash provides report identity, not tamper evidence. It confirms that two copies contain the same payload, but it is not a Requesty signature. Anyone who edits the payload can recompute the hash. Sign the downloaded JSON with your own key if you require cryptographic non-repudiation.
Use the information icon next to the page title to reopen Report details & verification after dismissing it.

​
Data Processing Agreement

The Compliance page also hosts Requesty’s Data Processing Agreement, pre-signed on our side:
1

Open the DPA

Select View DPA, then Open PDF.
2

Sign the customer sections

Have an authorized representative complete and sign the customer sections.
3

Return the signed copy

Email the completed PDF to [email protected].
A DPA with Requesty covers Requesty as a processor, not the upstream model providers. For provider-side terms, review the provider data practices surfaced in the Model Library or use BYOK so your own provider agreement applies.

​
Scope and limitations

The report is evidence, not a certification, and does not make your organization compliant with a framework. Its main limitations travel with every downloaded copy:
  • Traffic evidence currently covers chat completions only.
  • Requests recorded before guardrail verdicts were introduced have no scan outcome and appear as Not recorded.
  • Traffic and verdict counts use provider attempts; violation counts use user requests.
  • Model hosting locations and data practices use the catalog at generation time.
  • The configuration snapshot is current at generation time; use the audit log to establish when a policy changed during the reporting period.
Last modified on August 27, 2026