PAT security posture.

Authentication boundaries

Production authentication is provider-backed. Local review credentials are explicitly gated by environment and loopback rules so they are not confused with public production auth.

Sensitive operations

Billing and account-sensitive operations are protected by route-level guards, rate-limit checks, and elevated confirmation where supported by the current runtime. Session payloads are kept to the fields needed for routing and authorization.

Release and runtime proof

Startup preserves a dirty-tree guard, and release validators compare canonical root, branch, commit, build ID, build timestamp, auth mode, start command, and git dirty state across runtime artifacts.

Billing data boundary

Card entry is delegated to the payment provider when billing is configured. PAT stores provider identifiers and reconciliation status; it does not store raw card numbers.

Subprocessors

PAT relies on a small set of infrastructure and service providers to operate. We inherit each provider's own infrastructure controls; PAT does not claim its own external certification.

• Vercel — application hosting and edge/serverless compute.
• Neon — managed PostgreSQL database (pooled, with connection management).
• Stripe — payment processing and provider-hosted checkout when billing is configured.
• Anthropic — large-language-model provider powering optional AI-assisted features (no customer data is used to train third-party models).

Data practices and methodology

Data is transmitted over encrypted connections. Retention is configured per data class with a soft-delete window before hard purge, and tested tenant export and deletion paths exist for contractual data-subject requests. How PAT computes its scores and benchmarks — including the integrity walls that keep demo data and vendor self-report out of peer aggregates — is published on the versioned methodology page at /methodology.