Security & data handling

This page defines what Integrity processes, what it retains, and which controls you own.

What Integrity sees#

When you call the classifiers directly, Integrity sees exactly the fields you send: the text for INT-Input, reasoning and final output for INT-CoT, the request and proposed action for INT-Tooling, and the assistant response plus any context you pass for INT-Output. Those inputs can contain sensitive data, so you control what you submit.

When you route through the gateway, Integrity sees the full chat-completions request and response so it can classify them, then forwards the request to your upstream provider. How much of that content is retained afterward is set by the content mode below; classification itself always processes the content in memory for the duration of the request.

API keys#

Project keys are generated as tsk_ plus 64 hex characters. Only a SHA-256 hash of the key and a short prefix are stored. The raw secret is shown once and never persisted, so it cannot be recovered from the datastore. Rotate with Regenerate, which replaces the stored hash.

Content retention#

Gateway trace content is governed per project by the observability content mode:

Under metadata_only, the trace detail’s Payloads tab shows that content was not retained rather than storing message bodies.

Direct SDK and REST classifier checks are submitted to a bounded, best-effort security-event writer. When an event is persisted, it uses the explicit project content mode when one is set. Without an explicit mode, both direct-check events and gateway traces default to metadata_only. Queue saturation, an unavailable writer at startup, or a database write failure can drop an event without changing the classifier response. Do not use this telemetry as a durable audit log.

Selected high-risk control-plane routes, including policy, project-key, and invariant changes, synchronously write an authorization audit event before attempting the mutation and stop when that write is unavailable. The audit event and the following mutation are not one database transaction, so an allowed audit event records authorization to attempt the change, not proof that the change committed. Other control-plane routes may record audit events on a best-effort basis. These events do not include per-request gateway verdicts or direct classifier events.

What we store#

• Metadata: persisted records include decisions, verdicts, scores, reason codes, and latencies. Gateway traces and direct-check events retain supplied provider, model, and session identifiers even in metadata_only mode.
• Content: only as permitted by the content mode above.
• Credentials: the raw project key and upstream provider key are not persisted. The project key is stored only as a SHA-256 hash; the provider key is forwarded upstream.

Content scrubbing#

The gateway treats Responses-API shapes and tool/function-call fields as content. That means request input, instructions, output summaries, deltas, function-callarguments, sanitized tool arguments, reasoning_text, and final_output are scrubbed according to the project’s content mode. Trace metadata is size-bounded too, so large payloads cannot expand unbounded inside observability.

Retention & deletion#

The retention janitor purges SDK security events, gateway traces, and gateway spans. The production default is 90 days for each record type. A deployment can configure different windows. The janitor runs at startup and then daily. Deleting a project does not immediately purge existing security events, traces, or spans. They age out under retention unless a separate erasure process is run.

Content mode and retention solve different problems. Content mode controls what a record may contain. Retention controls how long the persisted record remains.

Thresholds and training#

The production runtime does not use traces or security events to update classifier weights, fit project thresholds, or change project policy. Changing the content mode does not enable any of those operations.

Project thresholds are current policy values edited by users with project.policy.write. INT-CoT separately uses a static source-model threshold shipped with its classifier artifact. See Thresholds and calibration.

These statements describe the production runtime. For contractual questions about offline data use, contact info@triage-sec.com.

Transport & storage#

The public service is served over TLS at https://integrity.triage-sec.com. Telemetry is held in a managed PostgreSQL database. Requests larger than 10 MiB are rejected before any guard or upstream call, bounding resource use. For isolated or data-residency deployments, see Deployment.

Integrity as an inline component#

Routing traffic through the gateway adds a component to your request path. The fail-open or fail-closed setting governs classifier error and timeout verdicts. It does not convert authentication, validation, policy-loading, upstream, or unexpected proxy failures into successful allows. The request-size cap plus per-service isolation bound the blast radius of a single bad request. Direct classifier calls return a verdict or an SDK error. Your application decides whether that failure allows or blocks its own operation.

Security disclosures#

Report a suspected vulnerability privately to security@triage-sec.com. Include the affected endpoint or package version, expected impact, and reproducible steps. Do not include API keys, customer content, or data you do not own. Avoid disrupting the hosted service, and coordinate public disclosure with Triage after validation and remediation.

Compliance#

For a security review, questionnaire, or data-processing agreement, contact info@triage-sec.com. Request current evidence for the specific deployment you plan to use.