Triage builds Integrity to help organizations evaluate AI workflows against their policies. Scoped authorization, encrypted content storage, controlled processing, and traceable operations protect the information used in those workflows.
Security documentation
Our customer security package explains the architecture, safeguards, and operating program behind Integrity:
- Security Overview: platform protections, operational security, shared responsibilities, and assessment status.
- Security Architecture and Data Handling: data flows, tenant boundaries, encryption, retention, and provider roles.
- Integrity Evaluation Plan: representative coding and support workflows, measurement criteria, and evaluation closeout.
These materials are also available in our Trust Center. Security and engineering teams can request supporting evidence or submit a questionnaire to info@triage-sec.com.
Scoped access and encrypted content
Authenticated workspace membership governs administration and evidence access. Service authorization binds requests to the relevant organization, project, deployment, and session. Supported exports retain their authorization boundary when the data is read. Shared hosted infrastructure uses logical tenant isolation.
Hosted connections use HTTPS. Saved provider credentials and supported retained session content use AES-256-GCM authenticated encryption. Protected session records bind ciphertext to their expected record context. Production database connections use TLS with certificate verification, and runtime services obtain sensitive configuration through managed secret storage.
Platform credentials, customer-model provider keys, and Integrity reviewer grants serve distinct purposes. Customers manage workspace participants and integration keys; Triage enforces the platform authorization boundary. The architecture guide details the storage and encryption scope.
Purposeful data processing
Integrity evaluates activity submitted through an enabled integration: instructions, conversation context, model responses, and tool calls or results. The configured customer model and Integrity evaluation components process the content relevant to their work. Retained evidence supports authorized investigation and evaluation.
The customer agreement and documented instructions govern processing of Customer Data. Triage's standard terms do not authorize unrelated model training or cross-customer reuse. Supported retention settings govern evidence availability; the deployment review records retention and cleanup across application records, runtime state, model providers, and backups.
Selected evidence views apply pattern-based redaction to recognized sensitive values. Customers should minimize sensitive inputs and review material before export. Live processing, retained originals, displayed evidence, and backup expiry have distinct lifecycles, described in the architecture guide and Privacy Policy.
Architecture and deployment scope
The hosted architecture separates workspace administration, workflow processing, model evaluation, and retained evidence. Principal service providers include AWS for application and database infrastructure, Modal for workflow and native runtime computation, Vercel for the web application, and Auth0 for portal authentication. The selected model routes determine additional inference providers.
A deployment review identifies enabled capabilities, data categories, processing locations, provider roles, and support responsibilities. Bring-your-own-key selects the credential for inference; Triage and the configured model provider remain part of that processing path. The actual data flow determines the applicable subprocessors and contractual disclosures.
Customer control and oversight
Customers configure the policies and supported interventions for their workflows. Observation and enforcement settings determine how Integrity's judgments affect a connected run. Retained session evidence supports review of those judgments and corrections.
Your agent harness, tool permissions, and downstream systems remain part of the control boundary. Validate the integration and intervention settings against your use case before enabling enforcement. AI judgments can be incorrect; appropriate human oversight and independent safeguards remain necessary.
Operational security and service continuity
Changes are managed through version control and pull requests. Automated checks exercise application behavior, tenant boundaries, SDKs, web components, and container packaging. Release evidence connects an identified source revision to its packaged image and deployed service.
Source, dependency, container, and infrastructure monitoring inform vulnerability review and remediation. Operational monitoring and synthetic workflow canaries provide evidence of service availability and representative request completion. Findings are tracked through investigation, remediation, and deployment verification.
The hosted environment uses automated database backups, encrypted snapshots, and monitored runtime backup jobs. Recovery planning covers application state and the versions needed to read restored records. Our policies also address employee training, device security, access reviews, vendor risk, and incident investigation and recovery. Customer notification, availability, and recovery commitments are established in the applicable agreement.
Assurance and assessment status
Triage organizes its security program around the SOC 2 Security criteria and uses Oneleet to manage the control inventory, policies, monitoring, and evidence.
- SOC 2 Type II: readiness and evidence review are in progress. An auditor-issued Triage report is not yet available. Observation-period and report dates will be communicated once confirmed.
- Independent penetration testing: scheduled. The completed report is not yet available.
- Customer diligence: the security package is available now, with additional evidence reviewed against the proposed deployment.
The Security Overview contains the dated assurance statement. Contact info@triage-sec.com for current assessment scope and evidence relevant to your review.
Controlled adaptation
Customer-specific adaptation uses reviewed material and separate preparation, training, evaluation, and activation steps. Permissions and the applicable agreement govern which data may be used. Retention settings and the availability of source evidence affect what can be reviewed and prepared.
Training and activation are separate: preparing examples or running a training job does not itself deploy a new version. Supported activation workflows include evaluation and rollback to a retained version.
Availability depends on the deployment connection. The current Base connection does not support customer-version preparation, training, activation, or rollback. See Versions and adaptation before planning a workflow that depends on those capabilities.
The customer agreement and documented instructions govern training permissions. The Privacy Policy and Terms do not authorize unrelated model training or cross-customer reuse of Customer Data.
A concrete evaluation path
An initial evaluation uses a separate workspace, public or synthetic cases, and controlled tool fixtures. Two representative workflows are a coding assistant repairing a bug while preserving authorization requirements, and a support assistant following an approved policy while interpreting retrieved documentation.
The Integrity Evaluation Plan defines the setup, case classes, and evidence to retain. Agree the task set, customer model, governing policy, request budgets, and acceptance criteria before comparing runs. Measure legitimate task completion, policy adherence, unnecessary interventions, latency, and available usage, including failed and incomplete cases.
The resulting engineering readout guides a scoped internal pilot. Customer data and internal systems are introduced within the agreed deployment and security requirements.
Customer security reviews
For a security questionnaire, deployment discussion, or information about applicable data processing terms and subprocessors, contact info@triage-sec.com with the subject Customer security review.
We can discuss:
- Data flows, processing locations, model providers, and subprocessors relevant to the deployment.
- Access controls, evidence retention, and return or deletion of Customer Data.
- Data processing terms, security responsibilities, and incident notification and cooperation terms.
- Current SOC 2 readiness status, available assessment materials, their scope and dates, and outstanding remediation relevant to your deployment.
- A scoped evaluation plan, success criteria, and requirements for progressing to an internal integration.
Detailed security information may be shared under appropriate confidentiality arrangements. Deployment-specific commitments are documented in the customer agreement and applicable data processing addendum.
Report a security concern
Send suspected vulnerabilities or concerns affecting Triage to info@triage-sec.com with the subject Security report. Include the affected service, a description of the issue, and the minimum steps or evidence needed to understand it. Contact us first to arrange a suitable way to share sensitive evidence.
Do not include passwords, API keys, or other people's data in an initial report. Avoid disruption, accessing another customer's information, or testing third-party systems. Obtain written authorization before conducting security testing of Triage infrastructure. This reporting channel does not itself authorize testing or establish a bounty program.