Security

#1. Architecture overview

Reckonry is a Next.js application running on Google Cloud Run, backed by a managed Cloud SQL Postgres instance. Cloudflare sits in front for DNS, TLS termination, WAF, and rate limiting. Background work (Karbon syncs, billing jobs) runs on Cloud Tasks and Cloud Scheduler. Secrets live in Secret Manager.

Development and production run as isolated environments with no shared infrastructure. PR-preview deploys land on an isolated preview service so they can’t race with the live environment’s traffic.

#2. Encryption

2.1 In transit

All traffic to reckonry.ai, auth.reckonry.ai, and the per-PR preview hostnames is served over TLS 1.2 or 1.3, with HSTS enforced and modern cipher suites only. Internal connections (Cloud Run to Cloud SQL, Cloud Run to Karbon, Cloud Run to Stripe) use TLS as well.

2.2 At rest

Cloud SQL volumes, object storage, Secret Manager values, and backups are encrypted at rest with Google-managed keys (AES-256). On top of that, the Karbon Access Key and Bearer Token your firm pastes into Settings › Karbon are envelope-encrypted with AES-256-GCM under a dedicated key stored in Secret Manager — so even an attacker with full database access cannot replay them without also breaching Secret Manager.

The wrapping key is granted only to the background sync workload; the user-facing web workload that serves your dashboards has no IAM permission to retrieve it and cannot decrypt the stored credentials. A compromise of the web tier alone would not yield usable Karbon credentials. Every sync run is recorded in the structured logs and metrics described in section 7, and any cross-tenant admin access goes through the audit-logged helper described in section 4.

#3. Authentication

3.1 Single sign-on

Sign-in is delegated to Google or Microsoft Entra ID via Auth.js v5. Reckonry never sees, stores, or transmits your password — we receive only a verified email and an opaque OAuth subject identifier from your identity provider. Whatever multi-factor, conditional-access, or device policies you have in place stay in place.

3.2 Cross-provider linking

If a Member signs in with Google one day and Microsoft the next using the same verified email, we link the two identities to the same person record. We don’t merge unverified emails.

3.3 Internal admin access

A small number of Reckonry support staff have an internal admin role gated by RFC 6238 TOTP and a separate audit log. Support actions (impersonation, trial controls, support deletes) require a fresh TOTP elevate every time; every action is recorded with actor, target, and timestamp.

#4. Tenant isolation

Reckonry is multi-tenant on a single database, with isolation enforced at the database, not at the application. Every tenant-scoped table has a Postgres row-level security policy keyed on a per-request tenant identifier set by the application. RLS is FORCEd on tenant tables, and the application connects as a non-privileged application role — it cannot bypass RLS even if a query is malformed.

Admin operations that need cross-tenant access run as an audited admin role through a small, atomic helper that writes an audit-log row inside the same transaction. There is no way to read another firm’s data from inside the application without an audit-log entry.

#5. Network & perimeter

• Cloudflare WAF in front of every public hostname, with managed OWASP rules and rate limits.
• The OAuth-bridge Worker enforces a strict allowlist on the redirect target so a leaked state token can’t be used to phish a sign-in to an attacker-controlled host.
• Cloud SQL accepts no public IPs; database access goes through Cloud SQL Connector with IAM authentication.
• Production secrets are scoped to the runtime service account; CI deployments use Workload Identity Federation, so no long-lived keys exist anywhere.

#6. Application security

• Strict Content Security Policy and the standard hardening headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, HSTS).
• CSRF protection on every state-changing route via Next.js server actions plus the Auth.js CSRF token.
• Stripe webhook signatures verified on every event; off-session charges include a tenant ID in the metadata so a replayed webhook from one firm can’t affect another.
• Karbon writes are off — Reckonry only reads. There is no code path that mutates your Karbon practice.
• Dependency updates land via dependabot, with an npm audit gate on every pull request.
• Every deploy is built from a tagged GitHub commit and recorded as an immutable revision; rollback is a single traffic-tag change.

#7. Operations

7.1 Backups & recovery

Cloud SQL takes nightly snapshots with point-in-time recovery enabled (7-day window). Snapshots and backups are encrypted at rest. Recovery is tested quarterly against a scratch instance.

7.2 Logging & monitoring

All Cloud Run requests, Cloud SQL audits, and structured application logs land in Cloud Logging with 90-day retention. Sync runs emit a sync.run_completed event with log-based metrics; PromQL alerts fire on lag, error rate, and failed sync runs. Stripe webhook deliveries are tracked in a dedicated idempotency table.

7.3 Access control

Production data is reachable only through the in-app support tooling (TOTP-elevated, audit-logged) or by an explicit break-glass procedure that requires a written reason and generates an audit-log entry. Engineering work happens against a dev environment that mirrors prod’s schema and controls; there is no shared database.

#8. Incident response

If we discover a security incident affecting Customer Data, we’ll:

1. Contain the incident and stop ongoing exposure.
2. Notify affected firm Administrators within 72 hours of confirming impact, with the facts we know and what we’re doing about it.
3. Publish a post-incident note within 30 days summarising root cause, timeline, and corrective actions.
4. Honour all statutory breach-notification obligations in your jurisdiction.

Service-impact incidents that don’t involve Customer Data are tracked publicly at status.reckonry.ai.

#9. Reporting a vulnerability

Safe-harbour scope. Good-faith research against reckonry.ai and the auth.reckonry.ai bridge is welcome. Don’t:

• Run automated scanners that generate > 10 req/s.
• Access another firm’s data — if you find a way to, stop, document, and report.
• Modify or delete data that isn’t yours.
• Run denial-of-service or social-engineering tests.

#10. Compliance

SOC 2 Type II — in progress. We expect to complete an initial Type I report in late 2026. The corresponding controls (change management, access reviews, vendor management) are already in place and audit-logged.

GDPR / Australian Privacy Act / CCPA — we comply with the rights and obligations described in the Privacy Policy. We sign data-processing agreements with firms in regulated jurisdictions on request.

Sub-processors. See the Privacy Policy for the current list. Each is bound by a data-processing agreement that limits their use of Customer Data to providing the relevant service to us.

Detailed control documentation. Architecture diagrams, the access-control matrix, the audit-log schema, and our control mappings to SOC 2 and the major customer security questionnaires are available to evaluating customers under NDA. Request access from [email protected]; we’ll respond within 2 business days.

#11. Contact

Security questions, vulnerability reports, and audit-evidence requests: [email protected]. We aim to respond within 2 business days.