Current controls, stated without borrowed assurance.

Requests are validated before model routing.

• Strict schemas. Input, model output, public review, disposition, and attestation shapes are bounded and validated.
• Identifier gate. The operator confirms the absence of client identifiers; detected identifiers are rejected before inference.
• Rate and budget limits. Review and attestation endpoints reject traffic above configured request limits.
• Timeouts and bounded retries. Provider calls cannot wait indefinitely; unavailable required lenses fail closed.
• Response projection. The browser receives the defined review schema rather than raw provider responses or routing secrets.

The applicable source-separation rule is enforced in code.

• An AI-generated source must declare its model vendor, which is excluded before reviewers are selected.
• A human-authored source must declare its originating team or role and is not assigned a model vendor.
• The completed response is rejected if it does not follow the separation rule for the declared source type.
• The completed response is rejected if it does not meet the required distinct-vendor floor.
• Requests set OpenRouter's per-request ZDR and data-collection-deny controls. OpenRouter documents those controls as routing only to endpoints covered by its Zero Data Retention policy and providers that do not collect user data; handling remains governed by OpenRouter's terms.
• Returned model identifiers are checked against the expected model maker.

The attestation endpoint does not trust the browser copy.

The server issues an HMAC over the canonical review and verifies it before constructing a record. Dispositions must cover every finding exactly once, and the final decision must be consistent with those dispositions.

Filed records are scoped to the authenticated firm. The request path does not create or alter database schema. A conflicting second attestation is rejected rather than silently overwriting the first.

Current service providers.

• Vercel. Application hosting and request execution.
• OpenRouter. Routing to configured model providers.
• Anthropic, Google, OpenAI, and xAI. Model inference where selected by policy and permitted by source exclusion.
• Neon. The database for accounts, credits, account Reviews, grading answers, and firm-scoped records filed through an authenticated archive session.
• Stripe. Card payments for Review credits; Teranode stores payment references, not card numbers.

See Trust for the content path and Privacy for retention choices.

Where data is stored.

Teranode stores account and firm data in a Postgres database run by Neon on Amazon Web Services in the US (Virginia). Neon encrypts data at rest (AES-256) and in transit (TLS 1.2 or 1.3) and is audited each year for SOC 2 and ISO 27001. Teranode itself has not completed a SOC 2 audit. The application connects with a restricted database login, and Teranode's founder approves every production change.

SOC 2 Type II is not yet engaged.

Teranode does not present a planned audit as completed assurance. Current diligence is based on the implemented controls, disclosed architecture, test evidence, and available vendor documentation. Contractual security terms and a DPA are discussed during an active firm review.

If there is a breach.

If we confirm a breach that affects your data, we notify you within 72 hours.

Report a security issue directly.

Send a description and reproduction steps to security@teranode.ai. Do not include client data, credentials, or unnecessary personal data in the report.