BYO-Key and Provider Terms (Addendum)
Last updated: 2026-06-26
What this Addendum is. These BYO-Key and Provider Terms (these "BYO-Key Terms," this "Addendum," or the "BYO-Key Addendum") govern the single most load-bearing commercial and security fact about the Services: the Customer brings and owns the relationship, accounts, and API keys with its model Providers; the Customer pays the Providers directly; and Recovea is a neutral conduit that proxies the Customer's in-path traffic using the Customer's own Provider Keys. Recovea does not resell, mark up, sponsor, fund, or take custody of Provider tokens or Provider spend, and earns approximately $0 in token cost of goods sold.
The honesty rule (load-bearing for this company). This Addendum describes the Services as they actually exist and operate today, not as any website, deck, or roadmap may describe them. Capabilities that are not currently active are not promised, warranted, or relied-upon here. Recovea promises only capabilities that exist today and that the Ledger can prove or the fail-open architecture can guarantee. Where this Addendum and any published page or marketing surface disagree, the discrepancy must be reconciled before the relevant claim is made, and — for signed and paying Customers — this Addendum, read with the Agreement, controls on the subjects within its scope (§0.3).
0. Status, parties, scope, and order of precedence
0.1 Parties. This Addendum supplements the agreement between Recovea, Inc., a Delaware corporation, with a registered/notice address of 2810 N Church St STE 89986, Wilmington, DE 19802 ("Recovea," "we," "us," or "our"), and the business organization that accepts it (the "Customer," "you," or "your").
0.2 Incorporation into the Agreement; DPA auto-incorporation. This Addendum is incorporated into, and forms part of, Recovea's Terms of Service ("ToS") and any Master Services Agreement ("MSA"), Order Form, Statement of Work, or beta / design-partner agreement between the parties (collectively, the "Agreement"). Where Recovea Processes Customer Personal Data (§1.18) on the Customer's behalf, Recovea's Data Processing Agreement (the "DPA") is automatically incorporated into, and forms part of, the Agreement — it does not require separate execution to take effect. The DPA includes Recovea's CCPA/CPRA service-provider terms and the US-state addendum by default; the international-transfer addendum remains dormant (US-only) but available if a non-US transfer ever occurs. Capitalized terms used but not defined in this Addendum have the meanings given in the Agreement, the DPA, and the shared defined-term set carried across the Recovea legal suite.
0.3 Order of precedence (narrow carve-out). The documents forming the Agreement are read together. In the event of a conflict, the following order of precedence governs, from highest to lowest: (a) a signed Order Form, where it expressly so states; (b) the MSA (which supersedes the click-through ToS for matters it covers); (c) the DPA (which controls for the Processing of personal data); (d) this BYO-Key Addendum, which controls only on the specific and limited subjects of Provider Key handling, Provider Terms responsibility, Provider Charges, and runaway-spend allocation; (e) other incorporated policies; and (f) the body of the ToS. For clarity, this Addendum's carve-out is narrow: it does not displace the DPA's data-protection terms, and it does not displace the Agreement's limitation-of-liability or indemnification architecture, which apply to this Addendum as set out in §11.
0.4 Business use only; eligibility. The Services are offered to businesses and organizations for business or professional use only, and not for personal, family, or household use. Each person accepting this Addendum must be at least 18 years old and, if accepting on behalf of an entity, represents and warrants that they have authority to bind that entity, in which case "Customer" means that entity.
0.5 No investor/securities considerations. Recovea is a bootstrap-funded US company; nothing in this Addendum concerns investment, securities, or fundraising.
1. Defined Terms
The following terms are used consistently across the Recovea legal suite.
1.1 "Services" — the Recovea AI-spend gateway and its control surface, together with all related software, applications, APIs, dashboards, and features Recovea makes available, as they exist from time to time. As they operate today, the Services include the in-path proxy for LLM API traffic (OpenAI-compatible /v1, Anthropic /anthropic, OpenRouter long-tail) at api.recovea.ai, the unified cost Ledger, budget caps / kill-switch and alerts (the Breaker), cost attribution and telemetry (the Meter), the dashboard, account, metering, and billing functions, and (on the paid tier) the applied cache/dedup Levers (the Optimizer). The free observe-only Scan and any other tools are governed by their own notices except where this Addendum applies. The Services may include optimization, additional features and capabilities Recovea may offer; any such capability is governed by the terms in effect when Recovea makes it available and is not active or licensed under this Addendum unless Recovea expressly states otherwise (§2.6). References to the "Service" mean the Services.
1.2 "Provider" — a third-party large-language-model or inference provider (for example, OpenAI, Anthropic, OpenRouter, and others the Customer configures) with which the Customer holds its own account.
1.3 "Provider Account" — the Customer's own account, contract, and billing relationship with a Provider.
1.4 "Provider Keys" (each a "Provider Key") — the API key, secret, or equivalent credential the Customer issues from its own Provider Account and supplies to Recovea so that Recovea can sign upstream calls to that Provider on the Customer's behalf. A Provider Key is the Customer's credential to the Customer's own Provider Account. Recovea acquires no right, title, license, or ownership interest in the Provider Account or any Provider Key, beyond the limited, revocable signing authorization in §2.3.
1.5 "Provider Terms" — each Provider's terms of service, acceptable-use, usage, content, rate-limit, geographic, model-eligibility, verification/KYC, data-handling/training, and billing policies, as the Provider may change them.
1.6 "Provider Charges" — all amounts billed by a Provider to the Customer's Provider Account, including amounts arising from traffic routed through the Services.
1.7 "Recovea API Key" / "rcv_ key" — the credential Recovea issues to the Customer (prefixed rcv_/rcva_) that the Customer's application uses to authenticate to Recovea (application → Recovea). It is separate and distinct from a Provider Key (Recovea → Provider). See §9.
1.8 "Upstream Call" — a request Recovea makes to a Provider, on the Customer's instruction, signed with the Customer's Provider Key, while the Services are in-path.
1.9 "in-path" — operating within the live request path between the Customer's application and the Customer's Provider, on the paid tier, such that Recovea proxies (transits) the request and response in real time. (The Free tier is observe-only, metadata-only, and not in-path.)
1.10 "Inference Content" — the request and response content (prompts and completions, and any data embedded in them) proxied in-path through the Services. Inference Content may contain the Customer's confidential data and personal data of the Customer's own end users.
1.11 "Usage Data" — the per-request cost and usage metadata (model, token counts, finish reason, timestamps, computed cost, route, status) Recovea records to operate, meter, and bill the Services.
1.12 "the Ledger" — Recovea's append-only, hash-chained, offline re-derivable record of Usage Data and the basis for any invoice. The Ledger is content-free: it contains no Inference Content and no Provider Key.
1.13 "Levers" — the byte-identical exact-cache and dedup/single-flight mechanisms Recovea applies in-path on the paid tier to produce measured (not "verified") cost reduction. Cached responses are byte-identical and are never synthesized by Recovea.
1.14 "Allowlisted Upstreams" — the set of Provider endpoints, together with the AWS service domains the Services require to operate, to which the Service host is permitted to make outbound network connections (see §3.6).
1.15 "Fees" — the subscription and any other amounts the Customer owes Recovea under the Agreement. Fees are separate from, and additional to, Provider Charges (§4).
1.16 "Aggregated/De-identified Data" — Usage Data and other operational data that Recovea has aggregated and de-identified so that it no longer identifies, and cannot reasonably be used to re-identify, the Customer or any individual, consistent with CCPA § 1798.140(m) and applicable anonymization thresholds, and which Recovea commits not to attempt to re-identify.
1.17 "Customer Content" — the data, prompts, completions, files, configurations, and other content the Customer (and its Authorized Users) submit to, route through, or generate using the Services, including Inference Content.
1.18 "Customer Personal Data" — personal data (or personal information) within Customer Content that Recovea Processes on the Customer's behalf in providing the Services, as further described in the DPA. Where Recovea Processes Customer Personal Data, the DPA governs that Processing (§0.2).
2. The BYO-Key model — the Customer owns and supplies the keys
2.1 The Customer brings its own Provider Key. The Services are neutral, multi-provider, OpenAI-compatible, and bring-your-own-key (BYO-Key). The Customer obtains its own API key from its own Provider Account and supplies that Provider Key to Recovea — typically pasted once into the Recovea dashboard during setup. Recovea does not issue, own, fund, sponsor, or control the Customer's Provider Account or Provider Key. The Provider Key remains the Customer's credential at all times.
2.2 Ownership, authority, and representations. The Customer represents and warrants that, for each Provider Key it supplies: (a) it is the Customer's own credential, issued from the Customer's own Provider Account; (b) the Customer has full right and authority to supply it to Recovea and to instruct Recovea to use it to sign Upstream Calls; (c) supplying it to Recovea, and routing the intended traffic, does not violate the applicable Provider Terms or any law; and (d) the Provider Key is valid and adequately scoped for the Customer's intended routing.
2.3 The Customer's instruction to sign; no Recovea ownership. By supplying a Provider Key and routing traffic through the Services, the Customer instructs and authorizes Recovea to use that Provider Key solely to sign Upstream Calls to the corresponding Provider for the purpose of providing the Services to the Customer. This authorization is limited to that purpose, non-exclusive, and revocable as described in §7, and confers on Recovea no right, title, license, or ownership interest in the Provider Account or Provider Key beyond that limited signing authorization. The Customer's configuration choices in the Services (tier, routes, enabled Providers, caps, alerts, logging mode, Levers, Provider pass-through flags) constitute the Customer's documented instructions; see the DPA.
2.4 No Recovea spend; no custody; no markup; no resale. Recovea pays nothing to Providers and holds none of the Customer's Provider spend. Recovea does not take custody of Customer funds for Provider Charges, does not resell Provider tokens, capacity, or inference, and adds no markup to Provider prices. The Customer pays its Provider directly under the Customer's own Provider Account and pricing (§4). Recovea earns no margin on Provider usage and has no economic interest in steering the Customer to any Provider. Recovea's token cost of goods sold for the Customer's Provider usage is approximately zero.
2.5 Recovea's compensation. Recovea's compensation under the Agreement is the subscription Fee set out in the applicable Order Form or the then-current published Pricing page, in each case for the tier the Customer selects (the Free tier is observe-only and in-path (metered, metadata-only, with no Levers or spend-control enforcement, and bodies not persisted by default); the paid in-path plans are the in-path gateway with the full control surface, applied cache/dedup Levers, and the Ledger). Billing frequency, proration, and any discount for longer terms are as stated in the Order Form or Pricing page. All pricing lives in the Order Form or Pricing page and is not fixed in the body of this Addendum.
2.6 Capability and pricing reservations (nothing additional is active unless separately agreed). Recovea may offer subscription, usage-based, and savings-/outcome-based pricing models, and may make available optimization, additional features and capabilities Recovea may offer. Any such additional capability or pricing model is OFF and not active under this Addendum. Recovea may introduce any additional or usage-based Fee, or any savings-/outcome-based pricing model, only via a separate Order Form requiring the Customer's separate, affirmative election and consent; no such Fee or model applies unless and until so agreed in a signed writing. Any such capability is governed by the terms in effect when Recovea makes it available and is not licensed or relied-upon under this Addendum unless Recovea expressly states otherwise. Consistent with the honesty boundary, the terms "verified," "settled," and "proven" are reserved for measures Recovea may make available in the future under separate terms, and at present the Services produce only measured (not "verified") cost reduction (§4.4).
3. How Recovea handles the Provider Key (the honest current control set)
3.1 One-time plaintext entry; never displayed again. The Provider Key is shown in plaintext only once — at the moment of entry, in the Customer's own browser session. After the Customer submits it, Recovea stores it encrypted (§3.4) and never displays it in plaintext again — not in the dashboard, logs, support tooling, exports, or APIs. The Customer is responsible for retaining its own copy of the Provider Key from its Provider; Recovea cannot reproduce it for the Customer.
3.2 Volatile-memory decrypt to sign; never returned; never logged in plaintext. When the Customer's routed traffic requires an Upstream Call, Recovea decrypts the stored Provider Key only in volatile memory, for the limited purpose of signing that Upstream Call, and does not write the plaintext Provider Key to persistent storage. Recovea operates the Service host to reduce the risk that a plaintext Provider Key is captured in crash, swap, or core-dump artifacts, including by restricting and managing such artifacts; no software control is perfect, and this is an operational control, not a warranty. After the one-time entry in §3.1, the Provider Key is never returned to the Customer, to any other Recovea tenant, or to any third party, and is never logged in plaintext.
3.3 Purpose limitation; inbound Recovea key stripped before upstream. Recovea uses the Provider Key only to sign Upstream Calls to the Customer's Provider in order to provide the Services to the Customer. Recovea does not use it to access the Customer's Provider Account for any other purpose, and does not use it for Recovea's own consumption of Provider services. The Customer's inbound Recovea API Key (rcv_/rcva_) is stripped before the Upstream Call so that it is not forwarded to the Provider (§9).
3.4 Encryption at rest — the honest model. Stored Provider Keys are encrypted at rest using AES-256-GCM, with the Customer's tenant UUID bound as additional authenticated data (AAD) to enforce strict tenant isolation. Honest disclosure of master-key protection: the AES master key that protects stored Provider Keys is, in the current deployment, a protected, environment-managed secret on the Service host — it is not today wrapped by a cloud key-management service (KMS), and there is no customer-managed key (CMK), per-tenant KMS encryption context, or hardware security module (HSM). The Customer should not assume any key-protection mechanism beyond the AES-256-GCM-with-tenant-UUID-AAD-and-environment-managed-master-key model stated in this §3 and the operational controls in §3.2–§3.3 and §3.6. This disclosure is intended to be prominent enough for a CISO/security reviewer to rely on, and is stated identically across this Addendum, the Security Statement, the DPA, and the Subprocessors page; no surface may imply KMS is live. Recovea does not warrant that any key-protection mechanism not expressly stated here is in place (§10.2).
3.5 The Provider Key is never part of metering. The Ledger records Usage Data only and is content-free (§1.12). The Provider Key is not recorded in the Ledger, in Usage Data, or in audit records, and request/response bodies (Inference Content) are handled as described in §6 (not as part of metering).
3.6 Egress allowlist. In the current deployment, the Service host's outbound network egress is allowlisted to the Allowlisted Upstreams — the Provider endpoints the Customer has configured plus the AWS service domains the Services require. The intent and effect is that neither the Provider Key nor Inference Content can be egressed to a destination outside the allowlist. This egress allowlist operates together with the volatile-memory-decrypt (§3.2) and never-returned/never-logged behaviors, and a closed server-side request forgery (SSRF) class, to protect the Provider Key in use. The allowlist is an operational control; it is not warranted to be free of error or to prevent all conceivable exfiltration vectors.
3.7 Data location; US-only posture. The Provider Key, like other Service data, is stored in AWS us-east-1 (N. Virginia), in the United States, in the current deployment. Recovea is a US (Delaware) corporation operating US-only. For US Customers there is no cross-border transfer of personal data. Any EEA/UK/Swiss international-transfer mechanics are dormant and live only in the DPA / its standalone transfer addendum; this Addendum is a pointer, not an independent transfer representation. See the DPA.
3.8 Audit-logged key-lifecycle actions. Sensitive key-lifecycle actions (mint, rotation, update, removal, and deletion on exit per §7.6) are recorded in Recovea's append-only key-lifecycle audit record.
4. The Customer pays the Providers directly — no resale, no markup, no token margin
4.1 The Customer bears all Provider Charges. The Customer bears the full risk of, and is solely responsible for, all Provider Charges, including Provider Charges incurred via traffic routed through the Services, whether arising from the Customer's own volume, misconfiguration, runaway loops or retries, abuse or compromise of the Customer's keys, model or price changes by the Provider, or otherwise. Recovea does not guarantee, cap, underwrite, reimburse, or otherwise limit Provider Charges, except as the budget-cap control in §5 may, on a fail-open / best-effort basis, assist the Customer in limiting them. For clarity, this allocates to the Customer the obligation to pay its Provider; it does not disclaim Recovea's own liability in damages for Recovea's breach of this Addendum or the Agreement, which is governed by §11, and nothing in this §4 limits liability to the extent prohibited by applicable law (including for Recovea's gross negligence or willful misconduct).
4.2 Recovea billing is separate. Recovea's billing to the Customer (via Stripe; see the Subprocessors page) is separate from, and additional to, the Customer's Provider Charges. A Recovea subscription tier, any "included" figure, or any tier threshold is a pricing-tier measure only; it is not a spend cap on Provider Charges and does not cause Recovea to stop, throttle, or limit Provider Charges at any level.
4.3 Cost visibility is informational; the Provider's billing controls. The real-time cross-provider cost visibility, the unified cost Ledger, attribution, and alerts are informational accounting features measured against a defined counterfactual on the Customer's own traffic. They report the Customer's spend; they are not a guarantee of any spend figure and do not themselves stop spend. Recovea's per-request cost is an estimate computed from token counts and a price table and reconciled toward Provider billing; the authoritative record of amounts owed to a Provider is the Provider's own billing, which controls in the event of any discrepancy with Recovea's metering.
4.4 No savings, uptime, or outcome guarantee. Any cost reduction the Levers produce is measured/applied byte-identical exact-cache and dedup only (realistic low single digits, higher only on cacheable traffic) and is labeled "measured" — never "verified." Recovea does not guarantee any savings amount or percentage, any financial outcome, any uptime or availability, or the accuracy, quality, or fitness of any Provider output. The site and this Addendum are deliberately free of savings percentages and dollar figures.
5. Budget caps, alerts, and the runaway-spend disclaimer (read this carefully)
5.1 What the budget-cap control (Breaker) is. On the in-path paid tier, the Services provide a budget-cap control with a kill-switch and spend alerts (default thresholds at 50%, 80%, and 95% of the configured cap). When the Customer configures a budget cap, the Services are designed to stop routing new Upstream Calls once the configured cap is reached, and to send alerts as spend approaches it.
5.2 The budget cap is a design objective, fail-open, and NOT a guaranteed hard stop. The budget cap and the Services' overall reliability rest on a fail-open design objective (§7.2): if the metering or control layer is degraded, unavailable, or in error, traffic is designed to pass through to the Provider rather than be blocked, so that Recovea does not become a single point of failure that locks the Customer out of its own Provider. The cap is therefore framed as "designed to stop," not "will stop." As a result, the Recovea budget cap is not a guaranteed hard stop on Provider Charges. Spend may continue to accrue at the Provider during any fail-open condition, evaluation latency, in-flight request, retry, or partially-metered window. The Customer must not assume that any Recovea cap, setting, or limit will, with certainty, prevent Provider Charges from accruing. During any fail-open, downtime, degradation, maintenance, or Baseline Passthrough condition, the Customer's traffic reaches its Provider on the Customer's own Provider Account, key, and pricing, and the Customer pays its Provider exactly what it would have paid absent Recovea. Recovea neither adds to nor discounts Provider pricing in that condition. Accordingly, no "difference," "overpayment," "extra charge," or "unoptimized premium" is incurred as against Recovea; the only thing not obtained is an optimization Recovea never guaranteed (§4.4; ToS §3.4, §11.3). Any amount premised on savings not applied during such a condition is a foregone and unrealized benefit for which Recovea has no liability (see Availability & SLA Statement §6.8).
5.3 The authoritative spend controls are the Customer's, at the Provider. Because the Recovea cap fails open, the authoritative, Recovea-independent controls available to the Customer are: (a) Provider-side spend caps, budgets, and hard limits configured by the Customer at its Provider; and (b) revocation of the Provider Key at the Provider as an out-of-band kill switch (§7.1). The Customer must configure Provider-side spend caps appropriate to its risk tolerance, monitor its Provider spend, and rely on these — not on the Recovea cap — to bound Provider Charges with certainty. The Recovea cap and alerts are a convenience layer on top of, not a substitute for, the Customer's Provider-side controls.
5.4 Runaway-spend allocation. As between the parties, Provider Charges are the Customer's obligation to its Provider in all events, including charges arising from runaway loops, retries, misconfiguration, abuse, key compromise, or a failure of the Recovea budget cap to stop spend. The mitigations Recovea offers (the budget cap, alerts, and the fail-open / base_url-revert escape hatch) reduce risk but do not transfer the obligation to pay the Provider. This allocation does not disclaim Recovea's own liability in damages for Recovea's breach of this Addendum or the Agreement (governed by §11), and applies except to the extent prohibited by applicable law (including for Recovea's gross negligence or willful misconduct).
6. Inference Content, retention, and Provider data-handling pass-through
6.1 In-path Processing of Inference Content. Because the Services are in-path on the paid tier, Recovea processes Inference Content to proxy and meter it. Inference Content is transited in real time to fulfill the request; transit is not, by itself, storage. By default, Recovea records Usage Data metadata in the Ledger and does not separately persist request/response bodies, except for the paid-tier cache described in §6.2 and any opt-in body capture the Customer enables.
6.2 paid-tier Levers and cached content. On the paid tier, the cache/dedup Levers store response content keyed by a request hash for the cache time-to-live (TTL), in order to serve byte-identical repeats and produce measured cost reduction. Cached responses are byte-identical and are never synthesized by Recovea. This cached content is the Customer's data, is subject to the Retention and Deletion Policy and the DPA, and is not used for any purpose other than serving the Customer's own repeat traffic.
6.3 Retention by tier. Retention is tier-based: Free 30 days / paid-tier 365 days for the data each governs; statutory billing records are retained for approximately seven (7) years; any opt-in body capture is governed by a short time-to-live (24 hours). The single number set is harmonized across the Privacy Policy, DPA, Retention and Deletion Policy, and this Addendum.
6.4 Immutable-Ledger erasure carve-out. The Ledger is append-only and hash-chained. When the Customer or law requires erasure, Recovea retains a content-free integrity record (a tombstone plus severance of customer_id → null) as permitted by law, so that the Ledger's integrity chain is preserved while personal data and Inference Content are removed. This carve-out is stated verbatim and controls identically across the Privacy Policy, DPA, Retention and Deletion Policy, Security Statement, and Acceptable Use Policy.
6.5 No training on Customer data, Inference Content, Service outputs, or the Ledger. Recovea does not use Customer Content, Inference Content, Service outputs, or the Ledger to train, fine-tune, or develop any AI or machine-learning model — Recovea's, a Provider's, or a third party's. Recovea may use Aggregated/De-identified Data (§1.16) to operate and improve the Services, subject to its no-reidentification commitment.
6.6 Provider data handling is the Provider's, under the Customer's relationship; pass-through flags. Once a request leaves Recovea for the Customer's Provider, the Inference Content is processed by the Customer's Provider under the Customer's Provider Terms. Recovea is not responsible for that Provider's retention, training practices, logging, or model behavior. Where a Provider offers data-handling controls — for example, zero-data-retention or no-training options, headers, or endpoints — Recovea will pass through the Customer's configured choice where the Services support it, but Recovea does not control and does not warrant the Provider's honoring of those options. The Customer is responsible for selecting, setting, and verifying such options in its Provider Account and in the Services' pass-through configuration.
6.7 Data-protection characterization — the Customer's Providers are NOT Recovea Sub-processors. As the Services operate today, the Providers the Customer chooses to route to act in connection with the Customer's own Provider relationship; Recovea's position is that they are the Customer's processors, recipients, or independent controllers — not Recovea's Sub-processors. The transfer, sub-processor, retention, and export architecture rests on this characterization, and it reads identically across the DPA, Subprocessors page, Privacy Policy, Security Statement, AI-Governance materials, and this Addendum. Recovea's Sub-processors are AWS, Stripe, Amazon SES, and Amazon Cognito, as set out in the Subprocessors page, which governs the authoritative roster.
6.8 AI-law characterization. As the Services operate today, Recovea's position is that it acts as an infrastructure/observability conduit and cost tool — and not as a provider, developer, or deployer of a high-risk AI system, nor a general-purpose AI model provider, under the EU AI Act, the Colorado AI Act, or other US state AI laws — and that deployer duties sit with the Customer. On that basis, Recovea's position is that it owes no affirmative content-monitoring or moderation duty and that its routing is not individual automated decision-making. If Recovea later makes available a capability that would change this characterization, that capability will be governed by the terms in effect when Recovea makes it available.
6.9 Regulated / special-category data. The Customer must not submit, route, or transmit through the Services any protected health information (PHI) subject to HIPAA, payment-card (cardholder) data subject to PCI DSS, biometric identifiers, government-issued identifiers, children's data, or other special-category or regulated data, unless and until separately agreed with Recovea in a signed writing and permitted under the applicable Provider Terms. Recovea is NOT a HIPAA Business Associate, and the Services are not HIPAA-, PCI-, or otherwise validated for regulated data. The Customer is solely responsible for compliance with laws applicable to its data and for not transmitting such data through the Services. See the Acceptable Use Policy.
6.10 Right to route. The Customer represents that it has all rights, consents, and lawful bases for the data it routes through the Services and that its instructions to Recovea are lawful.
7. Rotation, revocation, and exit — the real kill switches
7.1 Out-of-band kill switch — revoke at the Provider. The Customer may, at any time and independently of Recovea, revoke or rotate its Provider Key at its Provider. Revoking the Provider Key at the Provider immediately invalidates the credential Recovea holds and is the authoritative way for the Customer to stop Recovea (or anyone holding the key) from signing further Upstream Calls. This control does not depend on Recovea's availability and is the Customer's ultimate kill switch over its own credential and spend.
7.2 In-product exit — one-line base_url revert; fail-open. The Customer may exit the Services at any time by reverting its application's base_url from Recovea back to its Provider — a single, reversible configuration change. After revert, the Customer's traffic goes directly to its Provider on the Customer's own key and no longer flows through Recovea. A full Recovea outage is recoverable by the Customer in this one line. The Services are designed to fail open to baseline passthrough: a failure before the first token is designed to fall back cleanly to the Provider; once tokens begin to stream, a failure surfaces as a clean error, never a silent splice of substituted content. Fail-open is a design objective and an exit mechanism, not a warranty of uninterrupted service, of any availability, latency, or behavior, or that fallback will always succeed. Recovea does not claim mid-stream failover. The Customer is responsible for retaining the ability to perform the base_url revert.
7.3 In-product key removal/replacement. The Customer may update or remove a stored Provider Key in the dashboard. Updating replaces the stored encrypted value; the prior plaintext is not retained or recoverable by Recovea. Removal stops Recovea from signing new Upstream Calls with that key for subsequent traffic.
7.4 No Recovea-side cryptographic kill switch beyond the above. Recovea does not today provide a customer-managed, Recovea-side cryptographic kill switch (such as a customer-controlled key the Customer can disable to render stored keys unusable). The controls the Customer has today are revoke-at-Provider (§7.1), base_url revert (§7.2), and in-product key removal (§7.3) — and only revoke-at-Provider is independent of Recovea. The Customer should not rely on, or represent internally that it has, a Recovea-side cryptographic kill switch.
7.5 The Customer's duty to revoke on compromise; incident notice. The Customer must rotate or revoke its Provider Key promptly upon any suspected or actual compromise (of the key itself, of the Customer's Recovea account, or otherwise), and update or remove the Provider Key in Recovea accordingly. The Customer must notify Recovea promptly at security@recovea.ai of any suspected compromise affecting the Services. Recovea will notify the Customer of a confirmed security incident affecting the Customer's data in accordance with, and to the standard and timing set out in, the DPA's incident-notification provisions, which control the meaning of "security incident" and the notification timeframe; this §7.5 does not create a narrower or divergent obligation.
7.6 Provider-Key deletion on exit. On termination or expiry of the Agreement, closure of the Customer's account, downgrade from the paid tier to the Free tier, or the Customer's removal of a Provider Key, Recovea will delete or render cryptographically unrecoverable (crypto-shred) the stored encrypted Provider Key within thirty (30) days, subject only to the content-free integrity carve-out in §6.4. This window is harmonized with the retention windows in §6.3. After deletion, the Provider Key cannot be reproduced by Recovea; the Customer remains responsible for retaining its own copy from its Provider (§3.1).
8. The Provider relationship — the Customer's responsibility, Recovea's disclaimers
8.1 Provider Terms are the Customer's responsibility. The Customer's Provider Account is the Customer's own, and the Customer's contract for inference is directly with its Provider. The Customer is solely responsible for complying with each Provider's Provider Terms for all traffic the Customer routes through the Services, including without limitation: the content of prompts and completions; acceptable-use and content policies; model-eligibility, geographic, and use-case restrictions; rate-limit and usage rules; any verification, approval, or KYC requirements; data-handling and training-opt-out settings; and the Provider's billing terms. The Customer will ensure that its Authorized Users comply, and is responsible for their acts and omissions.
8.2 Routing through Recovea transfers no responsibility and creates no agency. Directing traffic through the Services does not make Recovea a party to the Customer's agreement with its Provider, does not make Recovea the Customer's agent for that agreement, does not make the Provider Recovea's subcontractor for Provider services, and does not shift Provider-Terms compliance to Recovea. Recovea is not responsible for, and disclaims all liability arising from, the Customer's compliance or non-compliance with any Provider Terms.
8.3 Provider actions against the Customer. Recovea is not responsible if a Provider suspends, throttles, rate-limits, deprecates a model for, or terminates the Customer's Provider Account for any reason, including reasons relating to the Customer's routed traffic or the Customer's violation of Provider Terms. If access is suspended or terminated by a Provider, it is the Customer's responsibility to resolve the matter directly with that Provider; each Provider retains sole control over access to its models.
8.4 Provider disclaimers (consolidated). Recovea is a neutral conduit and disclaims all liability arising from: (a) Provider availability, outages, latency, or rate-limiting; (b) Provider pricing or price changes; (c) model behavior, model availability, or output content (including inaccurate, harmful, infringing, or otherwise objectionable output); (d) the Provider's suspension, throttling, or termination of the Customer's Provider Account; (e) any change to the Provider's terms, policies, or APIs; and (f) the Provider's data-handling, retention, training, security, or intellectual-property practices. Recovea makes no representation or warranty regarding any Provider, and takes no position on the ownership or commercial usability of any Output. See the AI-Output and No-Guarantee Disclaimer.
9. Two distinct credentials (rcv_ vs Provider Key)
9.1 They are not interchangeable. The Recovea API Key (rcv_/rcva_) authenticates the Customer's application to Recovea and never authorizes spend at a Provider; it is stripped before the Upstream Call (§3.3). The Provider Key authorizes Upstream Calls to the Provider and never authenticates to Recovea. Compromise or rotation of one does not automatically rotate the other. The console/browser uses an opaque server-side session (rcva_-style); raw upstream identity tokens never reach the browser.
9.2 The Customer manages both. The Customer is responsible for rotating the Recovea API Key on suspected compromise of Recovea-side access, and for rotating/revoking the Provider Key at the Provider on suspected compromise of the Provider credential (§7).
9.3 Display behavior differs. The Recovea API Key may be shown per the credential-management UI; the Provider Key is shown in plaintext only once at entry and never again (§3.1). The Customer should not infer the storage or display behavior of one from the other.
10. Warranty disclaimer specific to key handling
10.1 AS IS / AS AVAILABLE. TO THE MAXIMUM EXTENT PERMITTED BY LAW, THE KEY-HANDLING CONTROLS AND ALL OTHER FUNCTIONALITY DESCRIBED IN THIS ADDENDUM ARE PROVIDED AS PART OF THE SERVICES "AS IS" AND "AS AVAILABLE," WITHOUT WARRANTY OR CONDITION OF ANY KIND. RECOVEA DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT, AND ANY WARRANTY ARISING FROM COURSE OF DEALING, USAGE, OR TRADE. This disclaimer is conspicuous for purposes of UCC § 2-316 and is mirrored, and never narrowed, across the ToS, MSA, Availability/SLA Statement, the Disclaimer, the Support policy, and any Beta terms.
10.2 No warranty of unstated or not-yet-available controls. Recovea does not warrant that any control not expressly stated here is in place, and does not warrant that any control not currently active (for example, AWS KMS envelope encryption, a customer-managed key or Recovea-side cryptographic kill switch, SSO/SAML/SCIM, RBAC beyond owner-only, high availability / multi-AZ, tested disaster recovery, SOC 2 / ISO 27001 / PCI, region pinning beyond the single region, an independently third-party-verifiable artifact, or a status page) will be delivered on any timeline or at all. Recovea does not hold SOC 2, ISO 27001, or PCI certification.
10.3 No warranty against all compromise. No security control is perfect. Recovea does not warrant that the Provider Key cannot be compromised, that the egress allowlist cannot be circumvented, that the budget cap will always stop spend, or that the Services will be uninterrupted or error-free. The Customer's out-of-band protections in §5 and §7 (Provider-side spend caps and revoke-at-Provider) are the Customer's primary safeguards and are within the Customer's control.
10.4 No SLA at present. No uptime or availability service-level commitment, and no service credit, is offered for the Services at present; the Services, including key availability, are provided on a best-effort basis. The fail-open design and one-line base_url revert are the Customer's safety net, not an SLA. See the Availability/SLA Statement. Any SLA must be express, measured, and in a signed Order Form.
11. Indemnification and liability allocation for key handling
11.1 The Customer's indemnity. In addition to, and consistent with, the indemnification obligations in the Agreement, the Customer will defend, indemnify, and hold harmless Recovea, Inc. and its officers, directors, employees, and agents from and against any third-party claim, and any resulting loss, liability, cost, or reasonable attorneys' fees, arising out of or relating to: (a) the Customer's misuse, mishandling, or failure to secure, rotate, or revoke its Provider Key or Recovea API Key; (b) the Customer's violation of any Provider Terms with respect to traffic routed through the Services; (c) Provider Charges incurred via the Customer's account or routed traffic (§4–§5); (d) the Customer's supply of a Provider Key it did not have the right to supply (§2.2); (e) the Customer Content the Customer routes through the Services; and (f) the Customer's use of the Services in violation of the Acceptable Use Policy or applicable law.
11.2 Recovea's IP indemnity (narrow and capped). Recovea will defend the Customer against a third-party claim alleging that the Services, as provided by Recovea and used in accordance with the Documentation and the Agreement, infringe a US patent, registered copyright, or trade secret, and will indemnify the Customer for amounts finally awarded or settled. This indemnity excludes any claim arising from: (a) Provider outputs, models, or services; (b) Customer Content, Customer Data, or Provider Keys; (c) any combination or modification of the Services not made by Recovea; or (d) use of the Services outside the Documentation or in breach of the Agreement. Recovea's sole obligation and the Customer's exclusive remedy for such a claim is, at Recovea's option, to procure the right to continue using the Services, modify or replace the affected portion, or terminate the affected Services and refund prepaid, unused Fees. This IP indemnity is subject to the General Cap in §11.4 (it is not uncapped).
11.3 Indemnification procedure. Each indemnity is conditioned on the indemnified party giving prompt written notice of the claim, granting the indemnifying party sole control of the defense and settlement (provided no settlement imposing a non-indemnified liability or admitting fault of the indemnified party is made without consent), and providing reasonable cooperation.
11.4 Limitation of liability. All of Recovea's obligations and potential liability relating to this Addendum are subject to the limitation of liability in the Agreement, which applies identically here:
- (a) Exclusion of damages (mutual). To the maximum extent permitted by law, neither party is liable for any indirect, incidental, special, consequential, exemplary, or punitive damages, or for lost profits, revenue, goodwill, data, or any lost, foregone, unrealized, unachieved, or expected savings, cost reductions, or efficiency gains, even if advised of the possibility and however such damages are characterized, including where contended to be direct.
- (b) General Cap. Except as stated in (c) and (d), each party's aggregate liability arising out of or relating to this Addendum and the Agreement will not exceed the greater of (i) the total Fees paid by the Customer to Recovea in the twelve (12) months before the first event giving rise to liability and (ii) US $25,000.
- (c) Enhanced (super) cap. For (i) breach of confidentiality obligations and (ii) breach of data-protection or security obligations, each party's aggregate liability will not exceed two times (2×) the General Cap. This enhanced cap applies symmetrically and identically to both parties and, for clarity, reaches a Recovea breach of its data-protection or security obligations that results in unauthorized disclosure of a Provider Key.
- (d) Uncapped matters. Nothing in this §11.4 limits: a party's indemnification obligations under §11.1–§11.2; the Customer's obligation to pay Fees or to pay its Providers (Provider Charges); the Customer's breach of the license, Acceptable Use, or IP-ownership terms; or a party's fraud, gross negligence, or willful misconduct, in each case to the extent such limitation is not permitted by applicable law.
11.5 Provider Charges; basis of the bargain. As between the parties, Provider Charges are the Customer's obligation to its Provider in all events (§4–§5); this allocation does not disclaim Recovea's liability in damages for its own breach, which is governed by §11.4. Nothing in this Addendum limits the Customer's obligation to pay Recovea's Fees or to pay its Providers. The risk allocations and limitations in this Addendum are an essential element of the basis of the bargain, were relied upon in setting the Fees, and survive and apply notwithstanding any failure of essential purpose of any limited remedy.
12. Dispute resolution; governing law; general terms
12.1 Governing law. This Addendum and any dispute arising out of or relating to it are governed by the laws of the State of Delaware, USA, excluding its conflict-of-laws rules, and excluding the U.N. Convention on Contracts for the International Sale of Goods.
12.2 Binding arbitration; class-action waiver. Except for the carve-outs in §12.3, any dispute, claim, or controversy arising out of or relating to this Addendum or the Services will be resolved by final and binding arbitration administered by the American Arbitration Association (AAA) under its Commercial Arbitration Rules, before one (1) arbitrator, seated in Wilmington, Delaware, conducted in English. The AAA Consumer Arbitration Rules do not apply (this is a business-to-business, business-property service). The Federal Arbitration Act governs the interpretation and enforcement of this section. Each party bears its own fees and costs as provided under the Commercial Rules. THE PARTIES WAIVE ANY RIGHT TO A JURY TRIAL AND ANY RIGHT TO PARTICIPATE IN A CLASS, COLLECTIVE, OR REPRESENTATIVE PROCEEDING; claims may be brought only in an individual capacity, and the arbitrator may not consolidate more than one party's claims. The arbitrator will issue a reasoned written award, and judgment on the award may be entered in any court of competent jurisdiction.
12.3 Carve-outs from arbitration. Notwithstanding §12.2, either party may: (a) bring an individual action in small-claims court within that court's jurisdiction; and (b) seek injunctive or other equitable relief for actual or threatened infringement or misuse of intellectual property or breach of confidentiality. These carve-out matters, and any action to compel or enforce arbitration, are subject to the state and federal courts located in Wilmington, Delaware, to whose personal and exclusive jurisdiction the parties consent. Disputes brought by non-contracting parties (for example, security researchers or third-party complainants) are outside any agreement to arbitrate and are subject to those courts. If the class-action waiver in §12.2 is held unenforceable, the entirety of §12.2 is void and these carve-out courts govern.
12.4 Changes to this Addendum. Recovea may update this Addendum to reflect changes in the Services or its controls. For signed Customers, material changes are governed by the amendment terms of the Agreement; for self-serve Customers, by the change-notice mechanism in the ToS, with notice given before changes take effect. Any change to the arbitration provision (other than a change to a notice address) may be rejected by the Customer by written notice within thirty (30) days, in which case the prior version of §12.2–§12.3 survives.
12.5 Auto-renewal and cancellation. Subscription Fees renew automatically per the Order Form or sign-up flow. Consistent with the federal Restore Online Shoppers' Confidence Act (ROSCA, 15 U.S.C. §8401 et seq.) and applicable state automatic-renewal laws (including California Bus. & Prof. Code §17600 et seq.), Recovea provides conspicuous renewal disclosure, obtains affirmative consent, sends a pre-renewal reminder for annual terms where required, and offers simple online self-serve cancellation at least as easy as sign-up (not gated behind support). B2B Fees are non-refundable for the remainder of a paid term except as expressly stated; Recovea may recover collection costs and chargeback fees as permitted by law and consistent with the Stripe flow. US sales-tax / economic-nexus posture applies; no EU VAT/GST.
12.6 Assignment. The Customer may not assign or transfer this Addendum or any rights or obligations under it, by operation of law or otherwise, without Recovea's prior written consent, except to a successor to all or substantially all of its assets or business (not a Recovea competitor) upon written notice. Recovea may assign this Addendum in connection with a merger, acquisition, reorganization, or sale of all or substantially all of its assets. Any other purported assignment is void. This Addendum binds and benefits the parties' permitted successors and assigns.
12.7 Force majeure. Neither party is liable for any failure or delay in performance (other than payment obligations) caused by events beyond its reasonable control, including acts of God, natural disasters, war, terrorism, civil unrest, labor disputes, governmental action, internet or utility failures, denial-of-service attacks, or failures, outages, rate-limiting, or changes by a Provider or other upstream third party.
12.8 Notices. Legal notices to Recovea must be sent to legal@recovea.ai and to 2810 N Church St STE 89986, Wilmington, DE 19802. Recovea may give notice to the Customer by email to the Customer's account or billing contact or by in-product notice. Operational contacts: Privacy — privacy@recovea.ai; Security — security@recovea.ai; DMCA — dmca@recovea.ai. One domain org-wide: recovea.ai.
12.9 Electronic acceptance and communications (E-SIGN consent). By clicking "I agree" (or an equivalent control), executing an Order Form, or using the Services, the Customer accepts this Addendum and consents, under the federal E-SIGN Act and applicable state law, to transact electronically and to receive notices, agreements, and disclosures electronically. Electronic records and signatures have the same legal effect as handwritten ones, and the Customer agrees that electronic communications satisfy any legal requirement that a communication be in writing.
12.10 Survival. The following survive termination or expiry as to events arising before then and as to amounts owed, and for so long as Recovea holds any residual Customer data: §2 (BYO-Key representations; ownership; no-resale / no-markup economics), §3 (Provider-Key handling obligations), §4–§5 (Provider Charges; spend risk; runaway-spend allocation), §6.4 (Ledger erasure carve-out), §6.5 (no-training), §6.7 (Sub-processor characterization), §7 (rotation, revocation, exit, and Provider-Key deletion on exit), §8 (Provider responsibility and disclaimers), §9 (credential separation), §10 (warranty disclaimer, including the fail-open and no-mid-stream-failover disclaimers), §11 (indemnification and liability), and §12 (dispute resolution and general terms).
12.11 Severability; no waiver; headings; entire agreement. If any provision of this Addendum is held invalid or unenforceable, it will be enforced to the maximum permissible extent and the remaining provisions remain in full force. No failure or delay in exercising a right waives it. Headings are for convenience only. This Addendum, together with the Agreement and the documents it incorporates, is the entire agreement between the parties on its subject matter and supersedes prior understandings on that subject matter, subject to the order of precedence in §0.3.
Last updated 2026-06-26. Entity: Recovea, Inc., a Delaware corporation.