Security and evidence

Integrity scopes access and execution to authorized workspaces, projects, deployments, and sessions. Credentials, encrypted evidence, and revision checks protect different boundaries. Your application continues to own the permissions and execution environment of its tools.

Security documentation and review#

The Security Overview describes platform safeguards, operational security, and assessment status. The Security Architecture and Data Handling guide covers the hosted data flow, provider roles, and technical boundaries. Both are available through our Trust Center.

A customer review records the deployment, model routes, processing locations, authorized access, retention and cleanup, incident terms, and evidence relevant to the intended workload. Triage's SOC 2 Security program is in readiness and evidence review with Oneleet; independent penetration testing is scheduled. Current report availability is stated in Assessment status. Send a questionnaire through the customer security review channel.

Credentials and authority#

The platform key authorizes deployment traffic. Your provider key authenticates customer-model inference. Integrity manages separate tenant-scoped grants for its reviewers. Signed-in workspace permissions govern administration and evidence access. The BYOK guide explains these separate paths.

Admission and release check the required scope and governing revision. Access checks join the key, project, organization, and deployment; evidence reads require authorized scope and active membership. Knowing another session's ID does not grant access to it. Shared platform infrastructure uses logical tenant isolation rather than a promise of dedicated hardware.

What encrypted storage protects#

Authenticated encryption checks that ciphertext belongs to the expected record context when it is read. Encryption keys are managed by the platform runtime. These controls do not mean each customer has a dedicated encryption key, or that every field in every system is encrypted by the same mechanism.

Sanitization and retained evidence#

The session integration retains supported request, proposal, and review evidence for its configured retention period. Runs and Data expose scoped projections with pattern-based redaction of selected evidence fields. Recognized patterns include certain credentials, email addresses, and other sensitive strings.

Redaction does not sanitize requests sent to your provider or Integrity reviewers, and does not erase encrypted originals. It cannot detect every secret or personal detail. Constitutions, identifiers, annotations, and other metadata need deliberate handling too. Use opaque session and operation IDs and remove unnecessary sensitive content before submission.

Data preparation can apply additional sanitization before an available training workflow. Inspect the prepared dataset, source lineage, and permitted use; do not assume a redacted screen means the original data is suitable for training or export.

Execution and abuse controls#

Configured project quotas, request and response size limits, call/token/time budgets, and serialized session operations bound admitted work. Schema checks and expiring exact-action permits constrain supported executor authorization. Keep outbound network controls, least-privilege resource access, sandboxing, and artifact validation in your application.

The harness must validate and durably consume permits before external actions. Application reports and retained signatures do not automatically prove effects. Control-plane audit records describe requests and actors. They do not prove that a requested mutation committed; inspect the durable operation outcome and governing transition.

Retention and unavailable evidence#

Expiry restricts platform access to retained content. It does not prove immediate deletion from every downstream provider, native service, or backup. Current connection capabilities determine which remote cleanup operations are supported. Review your provider's own retention settings separately.

Expired or withdrawn evidence can become unavailable for viewing, grading, or export. Minimal operation identity can remain necessary to prevent replay of uncertain work. Missing content must not become an assumed successful outcome. See Access and retention for workspace operation.

Plan a scoped evaluation#

Download the Integrity Evaluation Plan for a complete proposal, representative cases, measurement criteria, and closeout steps.

Start with a separate workspace and an enabled deployment whose connection capabilities have been checked. Agree the provider routes, participants, retention period, request budgets, and cleanup process. Use public or synthetic data, local fixtures, and simulated tool results. Keep internal repositories, production credentials, customer records, and tools that can affect real systems outside the evaluation.

Fix the task set, governing policy, customer model, and budgets before comparing runs. Include clean cases as well as violations, and have a reviewer label expected outcomes independently. Begin in Observe to inspect recorded judgments; assess supported Enforce behavior separately inside the isolated harness. Observe does not prevent actions, and an Integrity verdict does not prove that a tool effect occurred.

Agree acceptance criteria before the evaluation: legitimate task completion, missed violations, unnecessary holds or corrections, end-to-end latency, and available usage and cost. Report case counts, failures, incomplete reviews, and unavailable measurements alongside successful runs. Missing native review cost remains unknown; see Performance and usage.

Retain the session and operation identifiers, governing revisions, review evidence, and application outcomes needed to explain each result. At the end, revoke evaluation credentials and carry out the agreed retention and deletion process across the relevant services. Expiry is not proof that every provider or backup has deleted its copy.

This evaluation measures usefulness on the agreed cases. It does not approve an internal integration, replace a security assessment, or require customer-version training. See Connect a deployment and Versions and adaptation for current setup and lifecycle availability.