Legal

Recovea Security Statement

Last updated: 2026-06-26


0. Purpose, Status, and How to Read This Statement

This Security Statement ("Statement") describes the technical and organizational security measures that Recovea, Inc., a Delaware corporation ("Recovea," "we," "us," or "our"), currently has in place to protect the Service, and it distinguishes — clearly, deliberately, and in good faith — between controls that are LIVE today and controls that are PLANNED (designed, on our roadmap, or partially implemented but not yet something you may rely on). Recovea is a bootstrap-funded US company; nothing in this Statement concerns investment or securities.

We publish this Statement so that security, compliance, and procurement teams can perform diligence against an accurate, conservative description of what we actually do — not an aspirational one. Recovea will not describe a control as live unless it is in production today. Where we say a control is PLANNED, you must not assume it exists, and you must not rely on it for your own compliance posture until we publish that it has shipped.

This Statement is the conservative anchor for Recovea's security posture. No other Recovea document, web page, sales material, questionnaire response, or representation may describe Recovea's security as exceeding what is stated here. If any other Recovea communication conflicts with this Statement by claiming a stronger control than is described as LIVE below, this Statement controls and the stronger claim is an error you should report to security@recovea.ai.

This Statement is informational. It is incorporated by reference into, and qualified by, the Recovea Terms of Service / Master Subscription Agreement (the "Agreement"), the Data Processing Addendum ("DPA"), the BYO-Key Addendum, and the Privacy Notice. Capitalized terms not defined here have the meanings given in the Agreement. Nothing in this Statement is a warranty, guarantee, or service-level commitment, except to the extent expressly stated as a binding obligation in a signed Order Form or the Agreement. See Sections 13–15.


1. Definitions

For purposes of this Statement:

  • "Service" means, collectively and as an umbrella term, Recovea's hosted and related offerings, including spend metering and observability; cost optimization and request routing; spend control (budget caps and kill-switch); reporting and analytics; data integration; verification; software development kits (SDKs), command-line tooling, and APIs; the append-only cost record (the "Ledger"); and related managed services, together with any features and capabilities Recovea may add. The Service 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 Statement unless Recovea expressly states otherwise.

  • "Customer" means the business entity that subscribes to or uses the Service.

  • "Authorized User" means an individual the Customer permits to access the Service.

  • "Provider" means a third-party model or inference provider (for example, OpenAI, Anthropic, or OpenRouter) with which the Customer has its own account and agreement.

  • "Provider Keys" means the API keys or credentials the Customer obtains from, and uses with, its own Provider accounts.

  • "Inference Content" means the request and response payloads (including prompts, inputs, and model outputs) that pass through the Service in connection with the Customer's in-path traffic.

  • "Usage Data" means metadata about requests and responses (such as timestamps, token counts, model identifiers, latency, status codes, routing decisions, and computed cost), as distinct from Inference Content payloads.

  • "Customer Personal Data" means personal data contained in Customer Content or Inference Content that Recovea Processes on the Customer's behalf as a processor (or service provider) under the Agreement and DPA, for which the Customer is the controller (or business).

  • "in-path" means traffic the Customer routes through Recovea's gateway on the Customer's own Provider Keys.

  • "LIVE" means a control that is implemented and operating in production as of the "Last updated" date above.

  • "PLANNED" means a control that is designed, roadmapped, partially implemented, or otherwise not yet operating in production, and which must not be relied upon as if it were LIVE.


2. Operating Posture and Architecture (Why the Threat Model Is Narrow)

Recovea operates a bring-your-own-key (BYO-Key), in-path gateway. Understanding this architecture is essential to understanding our security posture, because it materially narrows what data Recovea holds and what trust Recovea must be granted.

  • The Customer owns the Provider relationship. The Customer brings and owns its own Provider accounts, relationships, and Provider Keys, and pays its Providers directly. Recovea is a neutral conduit that proxies the Customer's in-path traffic on the Customer's own Provider Keys. Recovea never resells, marks up, sponsors, funds, or takes custody of Provider tokens or Provider spend. Recovea is not a party to the Customer's agreements with its Providers.

  • The Customer's Providers are the Customer's recipients, not Recovea's sub-processors. When traffic leaves Recovea bound for a Provider the Customer selected, that Provider receives the data as the Customer's own processor / recipient / independent controller. This is stated identically across our DPA, Sub-processor disclosures, BYO-Key Addendum, Privacy Notice, and this Statement.

  • Recovea's own sub-processors are limited. Recovea's infrastructure sub-processors are Amazon Web Services (AWS) and Stripe, together with our transactional email and identity providers. The current Sub-processor list governs and is published separately.

  • Business posture. The Service is offered to business customers only, to Authorized Users who are 18 or older, and is not intended for personal, family, or household use.

This architecture means Recovea's "crown jewels" are a comparatively narrow set: the Customer's Provider Keys (encrypted), Usage Data and the Ledger, the Customer's account/billing data, and any Inference Content that transits or is cached. The controls below are organized around protecting exactly those assets.


3. Hosting, Region, and Network

  • Cloud provider and region (LIVE). The Service is hosted on AWS in the US East (N. Virginia) us-east-1 region, in the United States. Recovea does not currently operate the Service outside this region.

  • No multi-region or region pinning beyond the single region (PLANNED). Region pinning, additional regions, and geographic data-residency options beyond us-east-1 are PLANNED and are not available today. Do not represent to your stakeholders that Recovea offers region selection.

  • Egress allowlist (LIVE). Outbound network traffic from the Service is restricted by an egress allowlist limited to required destinations (the Customer's selected Provider endpoints and required AWS service domains). This is a core control: it constrains where data can leave the environment and is a primary mitigation against server-side request forgery (SSRF) and data exfiltration.

  • SSRF mitigation (LIVE). We have implemented controls designed to mitigate the SSRF class of vulnerability in the gateway request path — enforced in conjunction with the egress allowlist — so that user- or content-influenced request targets are not permitted to reach unintended internal or external destinations. As stated in Section 13, this is a design and engineering objective, not a warranty that every such attempt will be prevented.

  • Transport encryption (LIVE). Connections to the Service's public endpoints (including api.recovea.ai and the console) are served over TLS. We do not accept unencrypted transport for authenticated traffic.


4. Encryption (Read This Section Carefully — KMS Is PLANNED, Not Live)

This is the single most important section for any reviewer relying on Recovea for sensitive workloads. We state it prominently and identically wherever it appears.

  • Encryption at rest (LIVE). Sensitive data at rest — including the Customer's Provider Keys — is encrypted using AES-256-GCM. The encryption master key is environment-managed (held in the application's runtime environment configuration), not in a dedicated key-management service.

  • AWS KMS / BYO-CMK is PLANNED, not LIVE. Envelope encryption backed by AWS KMS, and a customer-managed key (BYO-CMK) "kill switch," are PLANNED and are not in production today. No Recovea surface may imply that KMS-backed key management or customer-managed keys are live. If your security requirements mandate HSM-backed or KMS-managed keys, or customer-held key custody, those requirements are not met today. We will update this Statement when KMS envelope encryption ships.

  • Additional-context binding (LIVE). Encryption of tenant-scoped secrets binds the tenant UUID as Additional Authenticated Data (AAD) in AES-256-GCM, so that ciphertext for one tenant cannot be successfully decrypted in the context of another tenant.

  • Decrypt-in-memory only (LIVE). Provider Keys are decrypted only in memory at the moment of use to authenticate the Customer's in-path request to its Provider, and are not written back to disk or logs in plaintext.

  • Encryption in transit (LIVE). See Section 3 (TLS).


5. Identity, Authentication, and Session Security

  • Fail-closed, opaque server-side sessions (LIVE). Browser and console authentication uses an opaque, server-side session model. Recovea's backend verifies the upstream identity provider once at the edge and then mints its own server-side session reference; raw upstream identity-provider tokens never reach the browser. The auth design is fail-closed: absent a valid, server-validated session, access is denied.

  • Edge identity verification (LIVE). Identity is verified at the edge against our identity provider (Amazon Cognito) once per session establishment; thereafter the opaque server-side session governs access.

  • Inbound key-prefix stripping before upstream (LIVE). Customer-issued Recovea API keys use the rcv_ prefix; console/session references use an opaque rcva_-style reference. Recovea strips inbound rcv_ / rcva_ credentials from requests before they are forwarded upstream to a Provider, so Recovea-issued credentials are never leaked to third-party Providers.

  • SSO / SAML / SCIM (PLANNED). Single sign-on (SAML), enterprise IdP federation, and automated user provisioning/deprovisioning (SCIM) are PLANNED and not available today.

  • Role-based access control (PARTIAL / PLANNED). Full RBAC enforcement across roles is PLANNED. At launch, account access is owner-only for privileged operations; roles may be displayed in the interface, and one read-only (Viewer) role is enforced. You should not rely on granular role separation beyond the account owner and the enforced read-only role until full RBAC ships.

  • Multi-factor authentication. MFA is available through our identity provider in line with that provider's capabilities. Recovea does not represent that MFA is enforced for all Authorized Users at launch; Customers are responsible for configuring authentication controls appropriate to their requirements. We will update this Statement if and when MFA enforcement becomes a standard, relied-upon control.


6. Tenant Isolation

  • Designed-and-tested tenant isolation (LIVE). The Service enforces tenant isolation. We design and test tenant scoping so that one Customer cannot access another Customer's Provider Keys, Inference Content, Usage Data, or Ledger, and data and operations are scoped to the owning tenant. Tenant scoping is reinforced cryptographically by the tenant-UUID-as-AAD binding described in Section 4. As stated in Section 13, this is a design-and-testing objective, not a warranty against every possible isolation defect.

  • Logical, multi-tenant model (LIVE). The Service is a logically isolated multi-tenant system; it is not a per-customer single-tenant deployment. Dedicated single-tenant or private-instance deployment is not offered today.


7. Application and Infrastructure Security

  • Least-functionality gateway. The in-path gateway is purpose-built to proxy, meter, and apply byte-identical Levers; it minimizes the surface that touches Inference Content.
  • Secrets handling. Provider Keys and other secrets are encrypted at rest (Section 4), decrypted only in memory at point of use, and excluded from application logs in plaintext.
  • Internal least-privilege access (LIVE). Recovea operates on a least-privilege basis. Administrative access to production systems is restricted to authorized Recovea operations personnel (today, a single operator), and Recovea staff do not access Inference Content except as reasonably necessary to operate, secure, troubleshoot, or support the Service, or as instructed by the Customer or required by law. This access discipline is described identically across the Privacy Notice, DPA, and this Statement.
  • Audit of key lifecycle (LIVE). Recovea maintains an append-only, key-lifecycle audit record of credential create/rotate/revoke events.
  • Change management. Code changes proceed through version control and peer review before deployment, and dependency and code review is part of our development process.
  • Honesty enforced as code (LIVE). Recovea enforces a "claims" integrity control across its pipeline and data layer designed so that an entry cannot be recorded as "verified" unless the system's integrity conditions are satisfied, preventing unsubstantiated "verified" assertions from being written by mistake. The internal mechanism by which this is enforced is confidential; what matters for reliance is that Ledger attestations cannot present as "verified" without satisfying the control.
  • Penetration testing / independent security assessment (PLANNED). Periodic third-party penetration testing and independent security assessment are PLANNED and not yet part of a published, exercised program. See Section 11 for vulnerability reporting.

8. Data Handling, Retention, and the Ledger

  • Controller / processor split. Recovea is the controller of its own account, prospect, marketing, and personnel data, and a processor of Customer Personal Data contained in Inference Content (for which the Customer is the controller). This split is stated identically across the Privacy Notice, DPA, and this Statement.

  • What we store. We store Usage Data (metadata) to provide metering, reporting, and the Ledger. Whether request/response bodies (Inference Content payloads) are persisted, or only Usage Data metadata plus a request-hash-keyed response cache, is governed by the Privacy Notice and DPA, which control.

  • Cache (LIVE Levers). The live cost Levers are byte-identical exact-cache and deduplication / single-flight only. Cached responses are byte-identical to what the Provider returned and are never synthesized by Recovea. Where a response cache stores response content keyed by request hash, that content is subject to the same encryption and isolation controls described above.

  • Regulated and special-category data. The Service is not HIPAA- or PCI-validated, and Recovea is not a HIPAA Business Associate. The Customer must not submit protected health information (PHI), payment-card (PCI) cardholder data, biometric identifiers, government-issued identifiers, children's data, or other special-category or regulated data through the Service unless separately agreed in a signed writing. The Customer is solely responsible for compliance and for not transmitting such data.

  • Retention. Retention periods, including statutory billing-record retention and any opt-in captured-body time-to-live, are defined in the Privacy Notice and DPA, which control. One harmonized retention regime governs across the document pack; this Statement does not restate specific durations so that the governing documents remain the single source of truth.

  • Data export, return, and deletion on termination (LIVE). During the term, the Customer may export its Usage Data and the hash-chained Ledger in the open recovea-chain-v1 format. On expiration or termination, Customer data is returned or deleted in accordance with the DPA and Privacy Notice, subject to the immutable-Ledger integrity carve-out below and to retention required by law.

  • Immutable Ledger erasure carve-out. The Ledger is hash-chained, append-only, and offline re-derivable. On a verified erasure request, Recovea severs and deletes identifying and content data, but retains a content-free integrity record (a tombstone plus a sever of customer_id → null) as permitted by law, so that the integrity of the historical chain is preserved without retaining personal data or payloads. Operator-run tooling (recoveactl erase-customer) performs this severance; at v1 it is operator-run and partly manual, and audit-verifiable erasure is PLANNED. This carve-out is stated verbatim across the Privacy Notice, DPA, Retention policy, AUP, and this Statement.

  • Aggregated / De-identified Data. Recovea may create and use Aggregated / De-identified Data that meets the de-identification / anonymization thresholds of applicable law (including CCPA § 1798.140(m)), subject to a no-reidentification commitment. Recovea takes no position on ownership of Provider Outputs.


9. Backups, Resilience, and Disaster Recovery (Single-Operator Candor)

We are candid here because over-promising on recovery is a common and dangerous failure mode.

  • Backups (LIVE). Recovea performs nightly logical database backups (pg_dump).

  • Restore is untested; no RTO/RPO (CANDID DISCLOSURE). As of today, backup restoration has not been exercised end-to-end in a test, and Recovea makes no Recovery Time Objective (RTO) or Recovery Point Objective (RPO) commitment. You should not rely on a guaranteed recovery window.

  • High availability / multi-AZ (PLANNED). HA / multi-AZ redundancy is PLANNED and not in production today. The Service may experience downtime, and there is no contractual uptime commitment or service-credit SLA at launch (best-effort only). See Sections 13–15.

  • Tested DR (PLANNED). A tested disaster-recovery program with documented, exercised runbooks and recovery objectives is PLANNED.

  • The real reliability mechanism is fail-open + reversible exit (LIVE, but not a warranty). The Service is designed to fail open: on a gateway fault, the architecture is designed to let the Customer's traffic proceed or surface a clean error rather than silently corrupting a response, and the Customer can re-point its base_url back to the Provider in one reversible line to exit the path. "Fail-open" is a design objective and a reversible exit — not an availability or correctness warranty, and not a guaranteed hard stop. Likewise, the budget-cap kill-switch is designed to stop spend at the configured threshold; it is described as "designed to," not "warranted to." Recovea never claims mid-stream failover: we fall back before the first token; once tokens stream, a fault surfaces as a clean error, not a silent splice.

  • Status page (PLANNED). A public status page is PLANNED.


10. Compliance, Certifications, and Audits (No False Certifications)

  • Recovea holds no security certification today. Recovea is not SOC 2 audited, not ISO/IEC 27001 certified, and not PCI DSS certified or assessed. Where we describe our practices as "aligned to" a framework, that means we design toward its controls; it does not mean we are audited or certified against it. We will never represent a certification we do not hold.

  • SOC 2 / ISO 27001 / PCI (PLANNED / "aligned to" only). These are on our roadmap and are described as PLANNED or "aligned to," never as held.

  • Payments / cardholder data. Recovea uses Stripe for payment processing and does not store full cardholder data on its own systems; card-data handling is performed by Stripe as a PCI-validated processor.

  • Verifiability today: Ledger export and offline re-derivation (LIVE). Today, Recovea ships Ledger export and offline re-derivation: any Customer can export the hash-chained Ledger and re-derive the cost record offline using the open recovea-chain-v1 format and a standalone verifier binary, without trusting Recovea's live systems. Independent, third-party verification of attestations is a future capability and is not available today. Any such attestation, certification, or trust-mark capability, if Recovea makes it available, will be governed by the terms in effect at that time and is not active or licensed under this Statement unless Recovea expressly states otherwise.


11. Vulnerability Reporting and Responsible Disclosure

We welcome reports from security researchers. Please report suspected vulnerabilities to security@recovea.ai. Our full Vulnerability Disclosure Policy governs scope, safe-harbor, and handling, and is published separately.

  • Good-faith safe harbor. We will not pursue or support legal action against researchers who, in good faith, comply with our Vulnerability Disclosure Policy, avoid privacy violations and service degradation, and give us reasonable time to remediate before disclosure.
  • No bug-bounty representation. Unless and until we publish a bounty program, no monetary reward is offered or implied.
  • Non-party forum. Security researchers and other non-contracting reporters are not bound by the Agreement's arbitration provisions; disputes with such reporters are subject to the courts specified in Section 18, not arbitration. See Section 17.

12. Incident Response and Breach Notification

  • Response. Recovea maintains an internal process to detect, triage, contain, and remediate security incidents, and to preserve relevant evidence.
  • Notification standard (uniform). In the event of a confirmed personal-data breach affecting a Customer, Recovea will notify the affected Customer without undue delay after becoming aware, consistent with the DPA and applicable law. We deliberately use "without undue delay" — not a fixed-hour deadline — everywhere, so the commitment is one we can actually meet; the operative breach terms, including content and cooperation obligations, are in the DPA, which controls.
  • Customer responsibilities. The Customer must keep its account credentials and Provider Keys confidential, configure access appropriately, and promptly report suspected compromise to security@recovea.ai.

13. No Warranty; AS-IS / AS-AVAILABLE; No Guarantee of Savings, Output, or Availability

THE SERVICE, INCLUDING ALL SECURITY MEASURES DESCRIBED IN THIS STATEMENT, IS PROVIDED "AS IS" AND "AS AVAILABLE," WITH ALL FAULTS. TO THE MAXIMUM EXTENT PERMITTED BY LAW, RECOVEA DISCLAIMS ALL WARRANTIES, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT, AND ANY WARRANTIES ARISING FROM COURSE OF DEALING OR USAGE OF TRADE (UCC § 2-316).

WITHOUT LIMITING THE FOREGOING, RECOVEA DOES NOT WARRANT THAT: (a) THE SERVICE WILL BE UNINTERRUPTED, SECURE, ERROR-FREE, OR FREE OF HARMFUL COMPONENTS; (b) ANY SECURITY MEASURE WILL PREVENT ALL UNAUTHORIZED ACCESS, LOSS, OR ALTERATION OF DATA; (c) ANY COST SAVINGS, EFFICIENCY, OR FINANCIAL OUTCOME WILL BE ACHIEVED; OR (d) ANY THIRD-PARTY PROVIDER OUTPUT WILL BE ACCURATE, AVAILABLE, OR FIT FOR PURPOSE. Any savings, cost, or efficiency figures are ESTIMATES unless Recovea expressly designates them "verified" in writing per the Agreement. There is no contractual uptime SLA; availability is best-effort, with no service credits. The PLANNED controls in this Statement are not warranties and create no present obligation.

The descriptions in this Statement of controls "designed to," "engineered to," "designed and tested to," or intended to mitigate or prevent a given risk (including SSRF mitigation, tenant isolation, fail-open behavior, and the budget-cap kill-switch) state design and engineering objectives and good-faith descriptions of our practices, and are not representations or warranties that any such control is, or will remain, effective against every threat or free of defects.

This Statement describes Recovea's security program as of its date and may change; it is not a representation that any particular control will remain unchanged or will be effective against every threat.


14. Fees, Billing, and Pricing Optionality (Cross-Reference)

This Statement does not set prices. Fees, billing, auto-renewal, and cancellation are governed by the Agreement and the applicable Order Form, consistent with the federal Restore Online Shoppers' Confidence Act (ROSCA, 15 U.S.C. § 8401 et seq.) and applicable state automatic-renewal laws (including Cal. Bus. & Prof. Code § 17600 et seq.), with clear renewal disclosure, easy online self-cancellation, and a pre-renewal reminder for annual terms. Recovea may offer and add features and alternative pricing or billing models, including subscription, usage-based, and savings-/outcome-based models; any savings-based or outcome-based model applies only on the Customer's separate, affirmative election and is governed by separately disclosed terms.


15. Limitation of Liability; Cap

The limitation-of-liability architecture in the Agreement governs and is incorporated here by reference; this Statement does not expand it. For reference, that architecture provides, to the maximum extent permitted by law:

  • (a) Exclusion of indirect damages (mutual). Neither party will be liable for any indirect, incidental, special, consequential, exemplary, or punitive damages, or for lost profits, revenue, goodwill, or data, even if advised of the possibility.

  • (b) General cap. Each party's aggregate liability arising out of or relating to the Service or this Statement will not exceed the greater of (i) the total Fees paid by Customer to Recovea in the twelve (12) months before the event giving rise to the liability, and (ii) US $25,000.

  • (c) Enhanced (super) cap. For (i) breach of confidentiality and (ii) breach of data-protection or security obligations, each party's aggregate liability will not exceed two times (2×) the General Cap in (b).

  • (d) Uncapped matters. The caps in (b) and (c) do not apply to: a party's indemnification obligations; Customer's payment obligations; Customer's breach of the license, Acceptable Use, or IP-ownership terms; or a party's fraud, gross negligence, or willful misconduct (to the extent not waivable under applicable law).

These limitations apply notwithstanding any failure of the essential purpose of any limited remedy and form an essential basis of the bargain between the parties. The Agreement's Limitation-of-Liability section controls and is aligned identically across the MSA, DPA, ToS, Incident, and BYO-Key documents.


16. Indemnification, IP, and Confidentiality (Cross-Reference)

Indemnification (including any IP indemnity), intellectual-property ownership and reservation of rights, and confidentiality obligations are governed by the Agreement and the DPA, and are incorporated here by reference. Recovea reserves all rights not expressly granted. Confidentiality obligations survive per the Agreement (with the trade-secret, Customer-Data, and Inference-Content carve-outs stated there). Without limiting the Agreement's restrictions, the Customer and its Authorized Users must not use the Service outputs, the Ledger, or any Service materials to train, fine-tune, or develop a machine-learning model or a competing service. "RECOVEA" is a mark of Recovea, asserted as a common-law mark (™ / ℠) until any registration issues.


17. Privacy and Data Protection (Cross-Reference)

Recovea's processing of Customer Personal Data is governed by the Privacy Notice and the DPA, which control over this Statement on any data-protection matter. Where Recovea Processes Customer Personal Data on the Customer's behalf, the DPA is automatically incorporated into and forms part of the Agreement and includes CCPA/CPRA service-provider terms and the US-state addendum by default. International data-transfer mechanisms (e.g., SCCs / UK IDTA / Swiss amendments) live solely in the DPA or a transfer addendum and remain dormant for the US-only launch posture. Contact the privacy team at privacy@recovea.ai.


18. Dispute Resolution, Governing Law, and Venue

This Statement is governed by the laws of the State of Delaware, excluding its conflict-of-laws rules; the United Nations Convention on Contracts for the International Sale of Goods does not apply.

Disputes between Recovea and a Customer or Authorized User arising out of or relating to the Service are subject to the dispute-resolution provisions of the Agreement, which provide for binding arbitration before the American Arbitration Association (AAA) under its Commercial Arbitration Rules, by one arbitrator, seated in Wilmington, Delaware, with judgment on the award enterable in any court of competent jurisdiction. The Agreement includes a class-action, collective, and representative-action waiver (claims may be brought only in an individual capacity). Carve-outs to court (the Delaware state or federal courts located in Wilmington, Delaware) apply to: (a) claims for injunctive or equitable relief for actual or threatened infringement or misuse of intellectual property, or breach of confidentiality; and (b) small-claims matters within that court's jurisdiction. Each party bears its own fees per the AAA Commercial Rules; the AAA Consumer Rules do not apply (this is a business-to-business, business-property service).

Non-contracting parties (including security researchers and other vulnerability reporters) are carved out of arbitration and may bring claims only in the state or federal courts located in Wilmington, Delaware. Nothing in this Statement waives any non-waivable right.


19. General Provisions

  • Relationship to other documents; precedence. This Statement is incorporated into and subordinate to the Agreement. Order of precedence is: a signed Order Form (where it so states) > the MSA > the DPA (for processing of personal data) > the BYO-Key Addendum (for Provider Key handling, Provider Terms, Provider Charges, and runaway-spend allocation) > incorporated policies (including this Statement) > the ToS body. This Statement does not displace the DPA or the liability/indemnity architecture.

  • Assignment. Neither party may assign this Statement except as permitted by the Agreement; it binds permitted successors and assigns.

  • Force majeure. Neither party is liable for delay or failure due to causes beyond its reasonable control, as provided in the Agreement.

  • Notices. Legal notices are governed by the Agreement and directed to legal@recovea.ai and the registered notice address at 2810 N Church St STE 89986, Wilmington, DE 19802. Security matters: security@recovea.ai.

  • Electronic acceptance. Electronic acceptance and records are valid under the U.S. ESIGN Act and applicable state UETA, as provided in the Agreement.

  • Entire agreement. Together with the documents it cross-references, this Statement reflects Recovea's current security posture and supersedes prior security descriptions; the Agreement constitutes the entire agreement on its subject matter.

  • Severability. If any provision is held unenforceable, the remainder continues in effect, and the unenforceable provision is reformed to the minimum extent necessary.

  • Survival. The disclaimers, limitations, and reservations in this Statement — including the AS-IS / AS-AVAILABLE disclaimer, the BYO-Key neutral-conduit and not-a-provider-party characterization, the fail-open and no-mid-stream-failover disclaimers, the limitation of liability, and confidentiality obligations — survive any expiration or termination of the Agreement.

  • Modification. Recovea may update this Statement to reflect changes in its security program. The "Last updated" date reflects the current version. For a material adverse change that downgrades a LIVE security control, Recovea will provide affirmative advance notice as provided in the Agreement, and the affected Customer may terminate the affected subscription in accordance with the Agreement. For non-material updates, continued use after an update constitutes acceptance of the updated Statement to the extent permitted by law.


20. Quick LIVE-vs-PLANNED Reference

LIVE today: AES-256-GCM encryption at rest with an environment-managed master key; tenant-UUID-as-AAD binding; in-memory-only key decryption; egress allowlist; SSRF mitigation enforced with the egress allowlist; designed-and-tested tenant isolation; opaque server-side, fail-closed sessions with edge identity verification; rcv_ / rcva_ stripping before upstream; least-privilege internal access; append-only key-lifecycle audit; nightly pg_dump backups; Ledger export + offline re-derivation; TLS in transit; live Levers limited to byte-identical exact-cache + dedup/single-flight.

PLANNED (do not rely on as live): AWS KMS envelope encryption and BYO-CMK kill-switch; SSO / SAML / SCIM; full RBAC (owner-only + one enforced read-only role today); MFA enforcement as a relied-upon control; HA / multi-AZ; tested DR with RTO/RPO; SOC 2 / ISO 27001 / PCI certification ("aligned to" only); penetration testing / independent security assessment; region pinning beyond us-east-1; status page; audit-verifiable erasure; independent third-party verification of attestations.


Security contact: security@recovea.ai. This Statement is the conservative anchor for Recovea's security posture; no other Recovea surface may exceed what is described as LIVE above.