Compliance
This page is a reference for the compliance posture of Tetrate Agent Router. It records the certifications and attestations the platform carries, how the underlying reports are obtained, the data-residency options enforced at the routing level, and the upstream-provider data-retention settings that apply in an evaluation environment. It is a lookup surface for an operator or security reviewer; the how-to procedures it points to live in the operations guides. The exact set of certifications, their current status, and provider-specific no-retention terms change over time and are governed by contract. None of the values on this page should be treated as a current attestation of fact. Certification status and provider terms must be confirmed with the Tetrate field and legal team for the specific engagement.
Certifications and attestations
The platform is operated against recognised security and controls frameworks. The table below lists the attestations typically discussed during an evaluation. Presence in this table is descriptive, not an assertion that a given certification is currently held or current; the live status is confirmed by Tetrate per engagement.
| Attestation | Scope | Status source |
|---|---|---|
| SOC 2 Type II | Operating effectiveness of security, availability, and confidentiality controls over a defined audit period | Tetrate contact |
| ISO/IEC 27001 | Information security management system certification, where available | Tetrate contact |
The underlying audit reports, the SOC 2 Type II report and any ISO/IEC 27001 certificate and statement of applicability, are not published in this documentation. They are made available under a non-disclosure agreement (NDA) through the Tetrate contact. Requests for the reports, the audit period covered, and the scope boundary should be directed to that contact rather than inferred from this page.
Data residency
Data residency determines the geographic region in which request data is processed and stored. The platform supports selectable residency so that traffic for a given engagement is confined to an approved region.
| Residency option | Description |
|---|---|
| US | Request processing and data storage confined to United States regions |
| EU | Request processing and data storage confined to European Union regions |
Residency is enforced at the policy and routing level rather than as a single account-wide flag. A routing policy directs matching traffic to the data plane and upstream targets that satisfy the required region, so different policies can carry different residency guarantees within the same deployment. The available regions for an engagement, and any region beyond US and EU, are confirmed with the Tetrate contact.
Configuration of residency at the policy level is described in Configure Data Residency and No-Retention. This page records what the options are; that guide records how they are applied.
Upstream-provider data retention
Each upstream provider has its own data-retention posture for the prompts and completions it receives. Where a provider supports a no-retention or zero-data-retention mode, a configuration under which submitted content is not retained or used for training, that mode can be applied to the provider integration.
The following points govern how retention is handled:
- No-retention settings are provider-specific. They can be applied only where the provider offers the capability, and the available terms differ between providers.
- The applied setting must be recorded per provider. For an evaluation environment, the retention mode in effect for each upstream provider is documented as part of the provisioning record so that a reviewer can verify which providers are running under no-retention terms.
- A provider that does not support a no-retention mode retains data according to its own default policy. The absence of a no-retention setting for such a provider is itself recorded.
The exact no-retention terms, the providers that support them, and any contractual conditions attached must be confirmed with the Tetrate field and legal team. This page does not assert that a specific provider is running under no-retention terms in any given environment.
The procedure for applying and recording these settings is covered in Configure Data Residency and No-Retention.
Audit evidence
Evidence that residency and retention controls are in effect, and that administrative actions are accounted for, is drawn from the platform's audit surfaces rather than from this document.
| Evidence source | What it provides |
|---|---|
| Audit log | A record of administrative actions (policy changes, provider and model configuration, and key management) with actor, action, and timestamp |
| Policy-decision export | A record of routing and policy decisions applied to traffic, used to demonstrate that residency and retention policies were enforced for matching requests |
The audit log is reviewed and exported through the workflow in Audit Platform Activity. The event schema for administrative actions, the fields available for each recorded event, is documented in Audit Log Events.
Related
- Configure Data Residency and No-Retention, applying residency and provider no-retention settings
- Audit Platform Activity, reviewing and exporting the audit log
- Audit Log Events, event schema for administrative actions
- Gateway Behavior, per-request data captured by the gateway
Where to go next