Security model for LedgerLine accounting infrastructure.

API Key Security

Bearer keys stay on the server.

• API keys are bearer credentials and must stay server-side.
• Raw API keys are shown once only.
• Stored API key material is hashed with a server-only pepper.
• Key prefixes and suffixes can be shown for identification without revealing the full key.
• Revoked keys are blocked.
• Inactive connected app environments are blocked.
• Invalid or missing API-key attempts are throttled.
• Last-used metadata exists for safe operational visibility.
• API keys must not be placed in browser code, mobile clients, public repositories, frontend environment variables, logs, or screenshots.

Scope Isolation

Tenant scope is derived, not trusted from clients.

• Public API organization, connected app, environment, and API key context is derived server-side from the verified API key.
• Trusted client-submitted scope fields such as organization_id, connected_app_id, app_environment_id, environment, and mode are rejected.
• Module toggles provide setup guidance and soft warnings today; future hard module enforcement may use a standard module_disabled error after separate rollout work.
• Dashboard routes use authenticated Supabase user sessions plus organization membership context.
• Public share and portal routes use hashed token validation.
• The current runtime relies on server-side organization scoping.
• RLS and Storage policy drafts exist, but they still require disposable/staging dry-run, review, and deliberate application before production confidence.

Rate Limits

Abuse protection sits alongside authorization.

• Broad public API per-key rate limiting protects normal API traffic.
• Invalid API-key attempts are throttled separately.
• Public token routes have throttling for share, portal, and document access surfaces.
• Accounting mutation buckets protect posting and reversal workflows.
• Document transfer controls protect upload and download surfaces.
• Rate limits are abuse protection, not authorization. Permission, status, idempotency, and business-rule checks still matter.

Public Tokens

Share and portal routes resolve hashed tokens.

• Share, portal, and payment-instruction routes resolve hashed tokens server-side.
• Revoked tokens stop resolving.
• Public token routes are throttled.
• Public PDFs and logos are served through LedgerLine routes.
• Raw tokens should not be logged or exposed in dashboards.
• Token expiry policy remains a future hardening lane unless separately implemented.

Accounting Integrity

Posting and reversal preserve auditability.

• Posting and reversal operations run server-side.
• Journal entries must balance.
• Original journal entries remain immutable.
• Reversals create new reversing journal entries.
• Duplicate posting and duplicate reversal are guarded.
• Documents and supporting files do not mutate accounting by themselves.
• Reports are read-only.

Runtime Readiness

Checks exist, but setup and QA still matter.

• Server-only environment validation utility exists.
• `/api/health` exists for coarse runtime checks.
• Read-only smoke-check script scaffolding exists.
• OpenAPI validation script exists.
• Deployment checklist and production readiness docs exist.
• RLS and Storage dry-run plan/checklist exist.

Platform Admin Safety

Platform visibility is hidden, allowlisted, and minimized.

• `/platform` is hidden and protected by the platform admin guard.
• Access requires a real Supabase session plus server-side allowlist.
• Organization roles do not grant platform admin access.
• The development auth bypass does not grant platform admin access.
• The platform dashboard is aggregate/minimized by default.
• Platform admin audit logs and support notes exist.
• No impersonation, tenant mutation, or accounting mutation exists in the platform admin surface.

Product Boundaries

Deferred providers remain deferred.

• The API Reference is read-only.
• No public API route is broadly blocked by module state today.
• Core accounting does not require Stripe, SendGrid, Plaid, OCR/AI, IRS e-filing, or payroll providers.
• Real email sending remains deferred unless implemented later.
• Stripe Checkout/payment collection remains deferred unless implemented later.
• Plaid bank feeds remain deferred.
• OCR/AI parsing remains deferred.
• IRS e-filing remains deferred.
• Payroll/HR remains deferred.
• LedgerLine is ready to enter setup/testing from the code side, not production-approved.

Where To Go Next

Pair security posture with implementation docs.