Security Policy
This document describes the security controls Porter Agents Inc. ("Porter," "we," "us," or "our") has in place to protect customer data, third-party integration credentials, and the production environment that powers our financial automation platform. It is published publicly so customers, prospects, and integration partners can review our practices.
Porter is built to handle sensitive financial and operational data. Our security approach focuses on limiting production access, enforcing company-scoped role-based authorization in the product, encrypting sensitive integration credentials, using private document storage with short-lived signed URLs, requiring manual production releases, monitoring key infrastructure and vendor surfaces, maintaining backup and restore procedures, and documenting incident response.
As of the date above, Porter has implemented a set of core technical controls and is actively maturing the surrounding audit and readiness program. Porter does not represent that it has a completed SOC 2, ISO 27001, or PCI DSS report today. Porter is in active SOC 2 readiness work, with SOC 2 Type I targeted first and SOC 2 Type II planned to follow after the required observation period.
1. Compliance Status
- SOC 2 Type I. In readiness work (targeted).
- SOC 2 Type II. Planned to follow Type I.
- ISO 27001. Not pursued at this time.
- PCI DSS (direct). Out of scope — see Payment Data Scope below.
2. Access Control
- Production system access is restricted to a small number of internal operators.
- Inside the product, Porter uses role-based authorization for member, admin, and owner boundaries. An investor role is read-only and explicitly allow-listed against specific surfaces.
- A production-backed authorization smoke test was run on April 22, 2026 and passed 24/24 checks on sensitive company-admin routes.
- Customer workspace routes validate the authenticated user against the requested company before returning or mutating company data. Tenant data access is scoped by company identifier at the application and repository boundary. Porter describes this as application-level and repository-level tenant isolation.
- Internal operator access is limited to named Porter operators with documented business need and is treated as privileged production access.
- Access reviews are part of Porter's operating security program across source code, infrastructure, identity, and other core vendors.
3. Authentication
- User authentication is delegated to Kinde, a SOC 2 Type 2 certified identity provider. Porter does not handle user passwords directly.
- Every authenticated API request is gated by a server-side role check using an identity-provider-issued token and per-company role verification.
- All product traffic is TLS 1.2 or higher with HSTS enforced; there are no plaintext endpoints.
4. Secrets And Token Storage
- Third-party OAuth and API tokens are encrypted before persistence using an application-managed encryption key stored as a deployment-level environment secret. Disconnect and revocation behavior is provider-specific, and tokens are never exposed to the browser.
- Plaintext tokens never appear in application logs, error tracking, or analytics telemetry.
- Token refresh and provider revocation workflows are handled server-side.
5. Payment Data Scope
- Porter does not store cardholder primary account numbers (PAN), CVV, or magstripe data.
- Card-present and card-not-present transactions are handled by PCI DSS attested payment processors (Stripe, Helcim) via tokenized integrations. Porter receives only post-tokenization transaction references and metadata such as last four digits, brand, and processor transaction identifier.
- This keeps Porter outside the direct PCI DSS scope while still enabling card-platform integrations for customer accounting workflows.
6. Change Management And Release Control
- Production releases do not happen automatically from code pushes.
- Frontend and backend production deploys are manual release actions.
- High-risk changes are validated through code review, targeted testing, and security checks before release.
7. Infrastructure And Data Protection
- Porter runs on managed cloud infrastructure (Render) with the application database on Supabase Postgres.
- Uploaded customer documents are stored in private Supabase Storage and accessed through short-lived signed URLs.
- Sensitive operational logs and audit trails are minimized to avoid storing raw secrets or unnecessary freeform payloads.
- Production database exposure posture and live deployment configuration are part of the recurring security review process.
8. Monitoring And Detection
- Porter reviews code and dependency alerts from core source-control tooling.
- Porter reviews infrastructure and data-platform security posture, including deployment configuration and database exposure.
- Application errors are captured in our error tracker with personally identifiable information scrubbing enabled.
- Application and vendor alerts are part of the ongoing security program where configured and relevant.
9. Backup And Recovery
- Porter maintains database backups and a documented restore procedure.
- A full production-backup restore drill was completed on April 22, 2026 against a scratch environment and successfully recovered the application schema and representative production data.
10. Incident Response
- Porter maintains a written incident, token-compromise, and restore runbook.
- The runbook covers containment, credential rotation, evidence preservation, rollback, and customer communication expectations.
- Porter also maintains a tabletop template for sensitive-data and token-compromise scenarios.
11. Vendor And AI Data Handling
- Porter uses a small set of service providers to operate the product, including infrastructure, identity, payments, observability, analytics/session telemetry, email, and AI services.
- Porter uses AI providers where product features require it. AI providers are contractually prohibited from using customer data to train their models, and temporary OpenAI document-extraction files are deleted after extraction.
- Porter uses analytics/session telemetry to operate and improve the product. Browser analytics and session-replay claims depend on live vendor masking, capture-scope, retention, and member-access settings.
- The current list of named subprocessors is published at /legal/subprocessors.
12. Reporting A Security Issue
If you believe you have discovered a vulnerability or security issue in Porter, please email security@buildwithporter.com. We will acknowledge receipt within one business day. Investigations are led by Porter's founder. Please do not publicly disclose suspected vulnerabilities until we have had a reasonable opportunity to investigate and remediate.
13. Frequently Asked Questions
Who can access production data?
Production access is restricted to a small number of internal operators, and access is reviewed across core systems. Within the product, role-based controls separate member, admin, owner, and investor actions.
How do you prevent unauthorized actions in the product?
Porter enforces company-scoped role-based authorization at the application layer, and production-backed smoke tests are run against sensitive company-admin routes to verify those boundaries.
How do you control production releases?
Production deploys are manual. Code pushes alone do not automatically release frontend or backend changes to customers.
Do you back up customer data?
Yes. Porter maintains backups and has a documented restore procedure. A restore drill on April 22, 2026 successfully recovered the application schema and representative production data into a scratch environment.
Do you monitor security issues?
Yes. Porter's security program includes recurring review of code and dependency alerts, infrastructure posture, database exposure, deployment configuration, access review, and incident-readiness artifacts.
Do you use AI vendors?
Porter uses AI providers where product features require it. AI providers are contractually prohibited from using customer data to train their models, and temporary OpenAI document-extraction files are deleted after extraction.
How long is customer data retained after termination?
Porter retains active workspace data as needed to provide the Service. After workspace termination, primary accounting records and uploaded documents are retained for seven years by default unless the customer contract, legal hold, or applicable law requires a different period. Deletion requests are handled within 30 days, subject to those retention requirements and managed backup expiry.
Do you use analytics or session replay vendors?
Porter uses analytics/session telemetry to operate and improve the product. Browser analytics and session-replay claims depend on live vendor masking, capture-scope, retention, and member-access settings.
Are you SOC 2 compliant?
Porter does not represent that it has a completed SOC 2 report today. Porter is in active SOC 2 readiness work, with SOC 2 Type I targeted first and SOC 2 Type II to follow.
Are you PCI DSS compliant?
Porter is outside the direct PCI DSS scope. Card data is handled by PCI DSS attested payment processors (Stripe, Helcim); Porter does not store PAN, CVV, or magstripe data.
Questions about this security policy or Porter's security program? Email security@buildwithporter.com.