Trust Center

Risk Profile

What's at stake, and why a customer-controlled installable changes the math.

The metrics below answer the standard questions in any procurement security review. Most of them are favourable for PeerAI Studio not because of vendor diligence — though that's there too — but because the product architecture itself confines blast radius.

a390ee4

Risk metrics

Each metric below maps to a section in CAIQ / SIG / VSAQ. Hover or click through for additional context.

Operating model
Scaffolding, not stack
PeerAI is not part of the customer's permanent stack. Studio accelerates development, modernization, and delivery; once the solution is built, the scaffolding can be removed and the customer keeps all artifacts. Input is yours. Output is yours.
Customer IP ownership
Yours, always
Code, architecture documents, ADRs, migration scripts, generated tests — every artifact Studio helps produce is the customer's. PeerAI claims no rights to inputs, outputs, or derived work.
Vendor lock-in risk
Structurally low
Conventional vendor lock-in comes from data gravity (your data sits in their infra) or feature gravity (your runtime depends on their service). PeerAI has neither: data stays on your endpoint, runtime stays in your control. Removing Studio does not require data migration or system rewrites.
Data access level
Customer-controlled
PeerAI never accesses customer code, prompts, model outputs, or database content. Studio is an installable client; data stays on the customer endpoint or in customer-contracted services (LLM provider, database).
Impact level
Local
A compromise of a single Studio install affects only that user's endpoint. There is no shared data plane; one customer cannot affect another's data. Lateral movement is bounded by the OS principal.
Recovery time objective (RTO)
N/A
Studio runs on the customer endpoint with no PeerAI-side production data plane. Customer-side RTO is governed by the customer's endpoint backup and re-install policies. Operationally, PeerAI's RTO for release hosting is 4 hours (GCS + GitHub redundancy).
Recovery point objective (RPO)
Customer-controlled
Customer-side RPO depends on customer backup of their endpoint. PeerAI does not hold customer content, so there is no PeerAI-side RPO for that data.
Deployment model
Installable desktop application
Tauri v2 (Rust shell) + React frontend + Python sidecar. Customer-installed; not multi-tenant SaaS.
Multi-tenancy
Single-tenant by architecture
Each install is a single tenant. No shared infrastructure between customers. Cross-tenant data leakage is not an applicable risk.
Hosting region for operational services
US (release hosting)
Release binaries and trust artifacts are hosted on Google Cloud Storage in US regions. Trust portal at trust.peerai.peerislands.io runs on Vercel's global edge.
Operational outbound from Studio
Customer-toggleable
Optional: Sentry (crash reports), Arize (LLM telemetry to customer-hosted endpoint). Both disabled by default in privacy-conscious deployments.

Why these answers favour the customer

Most SaaS trust portals reckon with multi-tenant blast radius, large data planes, cross-region replication, and shared subprocessors. PeerAI Studio is a different shape: scaffolding for AI-native delivery — an installable, customer-controlled platform where the operational data plane lives on the customer's machine and the model + data services are customer-contracted.

The result is that a number of risk categories simplify to "customer-controlled" or "not applicable." That's not us dodging — it's the architecture working in the customer's favour, by design.

The same shape produces an unusual exit story: removing PeerAI later costs almost nothing because the artifacts are already yours. See Operating Model for the full picture.

Where PeerAI does carry operational risk — release hosting, the public Trust Center, the optional Sentry/Arize endpoints — we publish posture (this site), scan daily, and respond to disclosures within 48 hours.