Effective September 15, 2026

Privacy for Inferock.

OpiusAI ("Inferock", "we", "us") provides reliable and accountable LLM inference with per-call evidence. This policy explains what data each surface processes and where the evidence boundary sits. OpiusAI Inc. ("OpiusAI"), a Delaware corporation headquartered in California, operates Inferock.

Review status

Last updated
October 15, 2026. Material changes will be posted here, and account holders may receive notice by email.
Local bench stays local
inferock-bench keeps provider keys, local event logs, and receipts on your machine unless you choose to share them.
Hosted Inferock evidence
The hosted proxy stores per-call usage, receipt, and failure evidence. Inferock Watch provider keys are stored in the KMS-backed vault.

Review status

Effective September 15, 2026; revised October 15, 2026.

This policy covers the public website, hosted Inferock, and the local inferock-bench posture described in the public documentation.

The policy is written the way Inferock writes receipts: concrete controls, concrete data paths, and no certification or recovery claim that is not backed by shipped product reality.

Data collected

Data categories by surface.

Website, waitlist, and contact information

If you submit a form or contact us, we collect the information you provide, such as name, work email, company, role, and message content. Requests to the website also necessarily include network information such as IP address, browser or user-agent, requested URL, referrer, and timestamp.

Account and workspace records

Hosted Inferock accounts may include user and admin email addresses, tenant or workspace identifiers, authentication and session records, onboarding state, support messages, plan or order-form records, and Inferock API key metadata. Inferock API keys are not stored back in plaintext after issuance.

Hosted proxy evidence

When you route traffic through hosted Inferock, we process the request body to send it to the selected model provider and to create measurement evidence. Stored canonical events include items such as tenant, provider, model, route, request identifiers, operation identifiers, status, timing, usage, cache fields, pricing status, body hash, optional request-secret digests, response content, tool calls, tool schema metadata, provider safety fields, citations, raw usage fields, and derived failure signals. This includes the text of the model's reply, or the provider's error message, kept for 18 months. See What we see and keep on a call.

Inferock Watch key handling

In hosted Inferock Watch mode, customer provider API keys are stored per tenant in the key vault. The shipped key path uses AWS KMS envelope encryption with tenant encryption context, a customer-managed KMS key with rotation enabled, and a DynamoDB key-vault table with AWS-managed table encryption, point-in-time recovery, and TTL for rotated records. Plaintext keys are used only as needed to verify or route provider requests.

Local inferock-bench records

inferock-bench is different from hosted Inferock. It runs on localhost by default. Provider keys stay in the local environment or local config file, local events are written under the user's inferock-bench home, and receipts stay local until the user copies, posts, attaches, or otherwise shares them. Local event files can contain response text, tool calls, tool schemas, model names, usage fields, timing, selected provider IDs or headers, and detector evidence.

Billing and commercial records

For paid or approved customer use, we may process order forms, plan records, account status, invoicing details, tax details, billing contacts, payment status, and service-mode information. Fees and economics are governed by the applicable order form or plan, not this policy.

How data is used

How data is used.

We use data to run the service, route calls, preserve evidence, secure accounts, and answer customer requests. We do not turn a receipt into a recovery promise or a compliance certification.

Operate Inferock

Authenticate tenants, route provider calls, verify Inferock Watch keys, stream provider responses, maintain account state, and keep the dashboard usable.

Produce loss reports

Create per-call receipts, usage records, failure signals, billing-integrity checks, loss report rows, and remedy-status evidence.

Administer accounts

Manage onboarding, support, billing, notices, security reports, customer requests, and waitlist or product communications.

Security and compliance

Detect abuse, investigate errors, maintain emission-completeness evidence, enforce terms, respond to legal obligations, and protect the service.

Sub-processors and sharing

Vendors and disclosures.

We share data only where needed to provide the service, follow customer-directed provider choices, comply with law, protect the service, or complete ordinary business operations.

Cloud hosting

Hosted Inferock runs on Amazon Web Services. The product code uses AWS services including Lambda, DynamoDB, KMS, SSM Parameter Store, SNS, SQS, Aurora PostgreSQL, CloudWatch, Cognito, S3, and CloudFront. The primary product AWS region is US West (Oregon), in the United States; edge assets may use AWS edge regions.

Model providers

When a customer selects a model provider, prompts, responses, request metadata, and provider credentials or account context needed for the call are sent to that provider. In Inferock Watch, the provider account and provider terms are the customer's. In Inferock Serve, provider handling is governed by the applicable order form.

Commercial systems

We may share account, support, billing, and contact records with service providers that help us operate the business. We will update this policy or customer terms before materially expanding subprocessors for hosted customer data.

Analytics and observability

The shipped hosted path uses CloudWatch logs and product databases for operational telemetry and evidence persistence. inferock-bench does not send local receipt or event telemetry to Inferock unless the user chooses to share it.

We use PostHog as our analytics processor to improve Inferock. Public website analytics collects page views and selected interaction events with product and environment properties, without recordings. Where GeoIP is enabled, PostHog derives approximate location from the connection's IP address and discards the IP address itself. Website analytics does not collect submitted form content, prompts, responses, or provider keys.

In the signed-in dashboard, we record page structure and interactions to see where people get stuck, masking all inputs and text in the browser before sending. Recordings link only to analytics sessions, without person profiles; they exclude network request/response bodies, headers and console logs.

Enable Do Not Track to disable analytics and recordings; both require enablement and a configured project key.

Legal and safety disclosures

We may disclose information when required by law, to enforce our terms, to investigate abuse or security issues, to protect rights or safety, or as part of a merger, financing, acquisition, or similar corporate transaction.

Sub-processor updates

Inferock Serve and dedicated inference may be fulfilled through a de-identified third-party model-hosting partner. Content sent for inference is transmitted without account identifiers or customer-identifying metadata; it is not used to train the partner's models and is not retained by the partner beyond serving the request. A current list of sub-processors is maintained and made available on request; customers are notified of material changes.

Retention, deletion, export and incidents

B1. Retention schedule.

  • - Prompt text: not kept, with three exceptions. For calls in the Gemini request format we keep your conversation and system instructions, and for every model we keep any tool definitions, both in the call record for 18 months; and a provider error message that we keep can repeat part of your request. Reply text and provider error messages: kept for 18 months in the call record, then deleted. See What we see and keep on a call.
  • - Money records: we keep records of top-ups, charges, service fees, taxes, balances and billing corrections, together with the billing and account details needed to identify those records and the balance owner, and records of acceptance of the applicable Terms. We keep these records while the account is open and for 7 years after the later of the transaction date or account closure. If law requires a longer period, we retain the required records for that period. These records support accounting, tax, billing disputes and unclaimed-property reporting. This money-record period does not extend retention of inference request or response content.
  • - Usage and metering records that are not needed as money records follow the billing and observation window plus the statement/dispute period, with an in-house default of 13 months. Records needed to support charges or balances follow the money-record period above.
  • - Account and identity data: kept for the life of the account and deleted on closure under B2, except the billing and account details needed for the money records and retained under their schedule above.
  • - Operational logs: most are kept for one month; one internal log has no time limit set today, and we are setting it to one month. See What we see and keep on a call.

B2. Deletion process.

Account closure disables access immediately and triggers deletion of account and identity data except the details retained with money records under B1. Call records, including reply text, any tool definitions and, for calls in the Gemini request format, your conversation: 18 months, then they are deleted automatically. Other usage and metering records are deleted at the end of their B1 window; money records are deleted at the end of their applicable retention period. Backups containing residual copies age out on the backup cycle, with an in-house default of no more than 7 days, and are not restored selectively. We handle written deletion requests within an in-house 30-day target, subject to the retention requirements above and applicable law. We log the deletion action and timestamp without content.

B3. Export process.

A customer may request a machine-readable export of its account-scoped data—including identity and configuration data, usage and billing records, and the reply text kept in your call records—by emailing contact@inferock.ai. We respond to export requests within 7 to 14 business days. We verify the requester's identity, keep any export tenant-scoped, and may route requests for organization-controlled data through the customer's administrator. Export requests remain subject to the rights and limits described below.

B4. Incident-response process.

Stages: Detect (alerts to a staffed destination + the login-to-call synthetic; customer/report intake) → Triage (severity + scope + whether personal data is affected; open an incident record) → Contain / mitigate (revoke keys, isolate, roll back to the last-good build as the go-live ops plan already rehearses) → Notify (affected customers per A7's without-undue-delay / 72h target when personal data is affected; status updates until resolved) → Remediate + post-mortem (root cause + the regression/control that prevents recurrence; recorded like the existing incident post-mortems, e.g. the 2026-07-21 TLS incidents). Owner: the on-call/support contact named in the go-live ops readiness (O1).

What we see and keep on a call

This section explains in plain words what Inferock receives and keeps when you send a call. It applies the same way to calls made with your own provider key and to calls on managed Inferock Serve, because both use one pipeline.

In short: today, on our standard routes, we keep the full text of each reply for 18 months. We do not keep your prompt text, except for calls in the Gemini request format and in the error case explained below. We do keep any tool definitions in your request word for word. We are changing all of this.

What we receive

  • On our standard routes your request and the model's reply pass through Inferock so we can route the call, measure it and bill it.
  • On our encrypted routes we only relay encrypted traffic. We cannot read your request or the reply.

What we keep for each call

  • A call record: your account, the model provider, the model, the result of the call including any failure type, the tokens billed and the tokens delivered, the cost and the time.
  • From your request we keep a fingerprint of the request body (a one way SHA 256 hash) and the generation settings you chose, such as the maximum number of tokens. For calls in any request format other than the Gemini format, we do not keep the text of your prompt. The next two points describe what we do keep.
  • For calls in the Gemini request format, we currently also keep your conversation and your system instructions word for word in the call record, for 18 months. We are changing this.
  • If your request includes tool or function definitions, we keep those definitions, including their descriptions, word for word, for every model, for 18 months.
  • If we find a secret such as an API key inside a request, we keep a fingerprint of it in place of the secret. Until our fix is live, a provider error message, a Gemini conversation or a tool definition that we keep word for word can still repeat such a secret.
  • From the reply we keep the full text of the model's reply, or the error message the model provider sent back, word for word, for 18 months. A provider error message can sometimes repeat part of your request.
  • We use the reply text only to check billing and to run automatic quality and safety checks on replies, such as spotting broken output or a leaked secret. We never use it to train any model. We are changing Inferock so that reply text and provider error text are kept encrypted for only a short period, which we plan to set at 7 days, and then deleted, and so that we no longer keep Gemini conversations, and from tool definitions keep only a fingerprint and the field names. We will update this section when that change is live.

What we do not keep

  • The text of the prompts you send in calls, with three exceptions until our fix is live: calls in the Gemini request format and any tool definitions, both as described above, and a provider error message, which can repeat part of your request and which we keep word for word in the call record and, in some error cases, in a service log. Prompts you save yourself in a test set are covered under Optional features.
  • Anything readable from calls on our encrypted routes. For those we keep only a billing receipt for each call.

Logs

  • Our service logs record request ids, the provider, the route, the model, the result, the spend and your IP address. Apart from the error case below, they do not record the text of your prompts or the replies. We keep most of them for one month. One internal log has no time limit set today, and we are setting it to one month.
  • In some error cases one of our services can log an error that includes part of a provider error message. We are fixing this.

How long we keep it

  • Call records, including reply text, any tool definitions and, for calls in the Gemini request format, your conversation: 18 months, then they are deleted automatically.
  • If a call record cannot be saved at first, a copy of it, with everything listed above, waits in a retry queue for up to 14 days. The queue is encrypted.
  • Logs: one month, as above.
  • Money records such as top ups and charges: as described in the Money records part of this page.
  • Backups: 7 days, encrypted. A deleted record can remain in a backup for up to 7 days.

Who can see it

  • You can see your own call records in your dashboard.
  • Inside Inferock, only the service itself and a small number of Inferock administrators can read call records. No one outside Inferock has been given access to the systems that store them, and call records are stored encrypted.

Training

  • We do not use your prompts, the replies or your call records to train any model.
  • For managed Inferock Serve, the hosting partner's terms with us say it does not train on your content and does not keep it after serving the request.

Your own key and managed Inferock Serve

  • Both use the same pipeline, so everything above applies to both.
  • With your own key, the model provider handles your call under your account and its own terms.
  • With managed Inferock Serve, we send your call to our hosting partner without your account details.

Optional features

  • If you save a test set (a golden set), we keep the prompts and the replies you put in it until you delete them. This happens only when you use that feature, and you can delete a test set at any time.

Analytics

  • The analytics tool records how you use the dashboard, with all text and inputs masked. It never receives your calls or call records, and it does not keep your IP address.

Deleting your data

  • To delete your account and its call records, email contact@inferock.ai. We handle written requests within 30 days, as described on this page. Today our team does this by hand: closing your account does not delete your call records on its own. A deleted record can remain in a backup for up to 7 days.

Audits

  • We plan an independent audit of how we handle call data as part of a future release, and we intend to publish the result.

Request headers

Security

Concrete controls in the shipped path.

Encryption and isolation

Hosted provider keys are encrypted with KMS envelope encryption, tenant encryption context, and a retained KMS key with rotation enabled. DynamoDB tables for key vault, API keys, and onboarding are configured with AWS-managed encryption where shown in the infra code. Request digest secrets are read from SSM SecureString, and service roles are scoped to the DynamoDB, KMS, SNS, SSM, and ledger actions they need.

Incident response

We triage credible reports about key storage, routing, local auth, telemetry, or package integrity at contact@inferock.ai. We have not claimed SOC 2, ISO, HIPAA, or similar certifications on this page.

Inferock Watch

Inferock Watch and Inferock Serve have different data postures.

In Inferock Watch, the customer keeps its own provider account and provider bill. Inferock stores the customer provider key in the hosted key vault, uses it to route selected calls, and stores evidence for usage, receipts, and failure analysis. Inferock Watch reporting is visibility on the customer's own provider bill; it is not a promise that OpiusAI will recover or credit every provider-side issue.

In Inferock Serve mode, OpiusAI may operate the provider relationship as part of the service only where separately approved in the applicable order form or plan. Inferock Serve credits, if any, are bounded service credits under those terms.

User rights

Rights, choices, and customer roles.

You may request access, correction, deletion, export, or marketing opt-out by emailing contact@inferock.ai. We may need to verify your identity and may route organization-controlled data requests through the customer's administrator. We may deny or limit requests where the law permits, including for security, billing, legal, or dispute-preservation reasons.

Processor/controller roles

For hosted customer traffic, OpiusAI generally processes customer data to provide the service under the customer's instructions and applicable order terms. For account, website, support, security, billing, and business records, OpiusAI uses data to administer and protect the service. OpiusAI Inc. is the controller of personal data in those records; contact us at contact@inferock.ai.

Inferock is not directed to children under 13. We do not sell personal information, and this policy does not permit us to sell hosted customer prompts, responses, provider keys, receipts, or local bench files.

Contact and effective date

Questions and privacy requests.

Privacy contact

Email contact@inferock.ai for privacy requests, security reports, and data questions.

Effective date

Effective September 15, 2026. Last updated October 15, 2026.

Consent package revision: go-live-terms v15 (2026-10-15) · Legal text effective: September 15, 2026

Data Processing Agreement · Retention, deletion, export and incidents