Trust & Security

1. Encryption & Data Protection

Managed cloud services encrypt stored customer data at rest, and browser and API traffic is protected with HTTPS/TLS, consistent with our Privacy Policy. Provider-managed keys protect the default deployment. Eligible Enterprise organizations may bring their own Cloud KMS key for their BigQuery datasets and supported cloud-storage resources; PipeLedger verifies protected datasets carry the configured key, and control of the key remains with the customer.

• Per-tenant data isolation. Each customer organization is provisioned its own BigQuery dataset prefix. Row-level security policy is defined in BigQuery and enforced in the application layer through organization-scoped service paths that evaluate that policy data on every governed request. Supabase is used for authentication and user management only.
• HMAC tokenization secrets. Per-organization HMAC secrets used by masking operations are stored in Google Secret Manager, never in application code or environment variables. Re-identifiable tokens (CUST_*, VEND_*, EMP_*, PROJ_*) emitted to LLM agents are derived from these per-org keys, so two tenants with the same native entity ID produce different tokens. Admins resolve tokens back to display names through a server-side workflow gated by role and audit evidence. A connected application receives original identities only when the accountable user or credential has the corresponding explicit identity grant; it never receives the tokenization secret.
• Append-only audit log. Material administrative and governance actions, including GL account-governance changes, clearance grants, approvals, and governed-query evidence, are recorded in an append-only audit trail.

2. Authentication & Access Controls

• Customer authentication. Email and password or Google OAuth are provided through Supabase Auth. TOTP-based multi-factor authentication is mandatory for every user account before accessing PipeLedger workspaces.
• Connected-app credentials. Issued bearer tokens are bcrypt-hashed at rest; the plaintext is shown only once at issuance and never persisted server-side. Tokens carry audience-binding metadata (RFC 8707) and are rejected when presented to a different resource.
• Optional IP allowlist. Each integration token may be scoped to a list of source IP addresses or CIDR ranges. A credential presented from outside its allowlist is rejected.
• Explicit governed access. Every integration token carries an explicit role (viewer / operator), scope (organization-wide or specific dimensions), account confidentiality clearance, and fixed privacy policy enforced at query compilation. Restricted access removes identifying fields while retaining the financial line. Highly Restricted access removes transaction grain and returns only ledger totals with the minimum accounting context required to interpret them; returned totals do not expose identities, scope metadata, or transaction counts.
• MCP interoperability. The Model Context Protocol server (mcp.pipeledger.ai/mcp) implements RFC 9728 Protected Resource Metadata, RFC 8707 audience binding, Origin validation against a configured allowlist, MCP-Protocol-Version header negotiation, and WWW-Authenticate challenge headers on 401 responses.
• OAuth and managed clients. PipeLedger supports authorization-server metadata, protected-resource metadata, managed OAuth clients, and connected-app credential issuance.

3. Vulnerability Management & Monitoring

• Dependency review. Production dependency changes are lockfile-pinned, reviewed through pull requests, and checked by the applicable build and test suites before release.
• Application error monitoring. The web application, MCP server, and Dagster orchestrator include Sentry integration with application-level scrubbing. Telemetry is operational evidence and is not a customer-facing source of raw provider, database, or stack-trace details.
• Service health endpoint. Both app.pipeledger.ai/api/health and mcp.pipeledger.ai/health expose shallow liveness responses without authentication for external monitoring. They do not prove downstream database or provider availability.

4. Sub-Processors

The following service providers support the current deployment. This operational list is reviewed as the architecture changes. Any contractual notice obligation is governed by the customer’s executed agreement, not by this informational page.

• Google Cloud. The core data backend. BigQuery (financial data warehouse), Cloud Run (extraction, transformation, and delivery workloads), Cloud Storage (DLQ + audit archive), and Secret Manager (credentials). All General Ledger data is stored and processed here. Region: us-east4 (Virginia, USA).
• Supabase. Application front end and configuration only: authentication, user management, organizational configuration tables, audit logs, GL account governance metadata, and access policies. Supabase does not store or process General Ledger contents; all financial data storage and transformation runs on the Google Cloud backend described above. Region: us-east-1 (Virginia, USA).
• Vercel. Web application hosting and REST API delivery. Edge network global, primary execution in iad1 (Virginia, USA).
• Chargebee. Subscription billing, invoice and payment workflows, and secure card-entry fields. Chargebee is a PCI-DSS Level 1 certified service provider and also holds SOC 2 Type 2 and ISO 27001 attestations. Chargebee receives billing contact, address, subscription, and payment-token metadata; raw card entry is handled within Chargebee’s secure fields.
• Cloudflare. Turnstile scripts and challenge services on authentication pages for abuse prevention. Cloudflare receives the browser, network, and challenge metadata needed to provide that service.
• Sentry. Error monitoring and performance tracing for configured services. Each integration must use its service-specific telemetry minimization and sanitization boundary; this page does not represent that raw application exceptions are suitable for telemetry. Region: United States.
• Dagster Cloud. Pipeline orchestration and scheduling. Dagster Labs holds a SOC 2 Type 2 attestation. Receives pipeline metadata, asset names, and run timing; does not receive General Ledger row content. Region: United States.

5. Privacy & Regulatory Compliance

• GDPR & CCPA. PipeLedger processes customer-provided ERP data to provide the Service and separately handles the account, billing, security, and operational records needed to operate it. PipeLedger is currently below the CCPA’s statutory applicability thresholds, and we nevertheless align our privacy practices with GDPR and CCPA norms, including data minimization and support for data-subject requests. Data-subject requests should be directed through the customer Administrator and are handled subject to applicable law and contract.
• HIPAA / PCI-DSS. Out of scope. PipeLedger is not designed to process Protected Health Information or payment card data; customer Administrators are responsible for ensuring such data is not extracted from upstream ERPs.

6. SOC 2

PipeLedger does not yet hold a SOC 2 report. We have made strong internal readiness progress and are continuing that preparation toward certification. The Service runs entirely on infrastructure providers that maintain their own SOC 2 and ISO 27001 attestations (Google Cloud, Supabase, Vercel), and our own technical controls are documented in Sections 1 through 3.

7. Data Residency

The primary application components are currently configured in the following United States regions:

• Supabase Postgres (application configuration and governance metadata) in us-east-1.
• BigQuery datasets (General Ledger warehouse), Cloud Run workloads, Cloud Storage buckets, and Secret Manager entries in us-east4.
• Vercel application hosting in iad1 (Northern Virginia, USA).

These component locations do not, by themselves, establish that every provider copy, support record, telemetry event, backup, or network operation remains in one region. A contractual residency commitment exists only when stated in an executed agreement.

8. Incident Response & Breach Notification

PipeLedger investigates suspected security incidents and coordinates customer communication through the accountable contact. Notification timing, recipients, and required content are governed by applicable law and the customer’s executed agreement.

Customers may report suspected vulnerabilities or security incidents using the security contact in Section 10. Reports are tracked for triage; this public page does not establish a response-time SLA.

9. Contracts & Data Processing

For customers on the Enterprise plan, PipeLedger completes security questionnaires and can provide a Master Services Agreement (MSA) and Data Protection Agreement (DPA) during the procurement process. Only the documents executed by PipeLedger and the customer establish processor roles, subprocessors, retention, deletion, incident notification, audit rights, or residency commitments.

Use the contact in Section 10 with your organization name and procurement contact to ask which documents are currently available. No amendment or turnaround commitment is made on this page.

10. Contact

Security inquiries, vulnerability reports, DPA requests, and procurement questionnaires: support@pipeledger.ai.

For product or account help before subscribing or if you cannot sign in, visit our public support page or email the same address. Our standard initial-response target is within one business day. Subscribers can use the secure in-app Communication Hub for live support when available and for tracked tickets at any time.