Taxerity.AIsecurity & trust posture. Seven sections — implementation details, limits, and open review.

The current implementation has an app-layer AES-256-GCM envelope for selected fields before database persistence. The reviewed paths include Client.taxId, Communication.body, and DeductionSuggestion.reviewNote; this is not a claim that every sensitive or uploaded payload is covered.

The active 32-byte key lives in env.SECURITY_ENCRYPTION_KEY (base64); the active key version is tracked in an EncryptionKey manifest row in the app schema, not pinned only by env var. When ops rotates, a new EncryptionKey row with version=N+1 is written and the prior row is stamped supersededAt=now(); old ciphertexts stamped v=N continue to decrypt under their own row manifest. If a ciphertext stamped with a superseded version outlives SECURITY_ENCRYPTION_ROTATION_GRACE_DAYS (90 days), decryptField raises a typed EncryptionUndecryptableError(grace-expired) — no silent fall-through to plaintext and no fall-through to the active key. A version the system has never seen throws unknown-key.

The app does not claim that every stored or uploaded payload is covered by the same field-level path. Review storage, provider, and deployment controls before using taxpayer data.

The repository configures browser-facing headers including HSTS and CSP. Actual transport, hosting, and third-party connector behavior depends on deployment and provider configuration.

Per-request CSP nonce + frame-ancestors none are wired in proxy.ts (Next 16 proxy, no middleware.ts): the proxy generates a fresh nonce via crypto.randomUUID per request, builds the policy via buildCsp in src/lib/csp.ts (script-src nonce + strict-dynamic, no unsafe-inline/unsafe-eval in production), and pins frame-ancestors 'none'. X-Frame-Options: DENY rides alongside as defense-in-depth for older browsers (CSP frame-ancestors obsoletes it per OWASP, but pinning both is the lower-risk posture for a marketing surface that embeds no third-party widgets).

Permissions-Policy (built from appCapabilities in next.user-config.ts), Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Resource-Policy: same-origin, Referrer-Policy: strict-origin-when-cross-origin, and X-Content-Type-Options: nosniff are all pinned in next.config.ts so a deployment can never silently lose one of them — every header is explicit and asserted at build time.

Taxerity.AI sign-in runs through better-auth (src/lib/auth.ts) with two modes — passwordless email magic-link and classic email/password — both wired in src/lib/auth-config.ts. There is no anonymous-write path: every per-user /api/* route handler starts with let user; try { user = await requireAuth(req); } catch (res) { return res as Response; } so a missing or expired session returns a 401 without redirecting the fetch. Every per-user query in those handlers is scoped where: { userId: user.id } so a session token from one user cannot reach another user's clients, returns, communications, or suggestions.

Admin access is its own boundary. requireAdmin() (src/lib/require-admin.ts) redirects any signed-in user whose better-auth role is not admin back to /login or /, so the admin dashboard and the key-rotation endpoint sit behind a single role check — never a hard-coded password, never a custom admin cookie, never a shared secret. Key rotation itself is admin-only and audit-logged: it writes a new EncryptionKey row, stamps the predecessor supersededAt=now(), and emits a DataAccessAuditEvent of kind EXPORT against the encryption_key resource so the rotation is itself an audit-relevant action.

The auth configuration includes session expiry and admin gating. MFA is not enabled for every account by this application; do not represent the current configuration as universal MFA or a complete security posture.

The application uses firm and member records plus scoped route queries for the reviewed data paths. Automated tests cover selected cross-firm cases; the release report lists uncovered surfaces and the remaining review.

A trial or membership record is not a blanket guarantee for every route, connector, or deployment. Review the current evidence before using real taxpayer data.

Membership is the control, not the URL. A user cannot "visit" another firm's workspace by guessing a path — the route handlers, the data plane, and the access-audit layer all read authorship from FirmMember, so the boundary is enforced at three layers, not just painted onto the UI.

Treasury Circular 230 §10.35 puts the duties of confidentiality, competence, diligence, and appropriate supervision on the practitioner — the firm's signer under the firm's PTIN, not the tool. Taxerity.AI is a drafting helper; the return that ships is your firm's return, signed by your signer, under your EFIN and PTIN. Confidentiality of taxpayer information is therefore a practitioner duty the platform must support, not own: the access controls above (firm-scoped tenancy, field-level AES, per-firm access logging) exist so the practitioner can answer §10.35 from evidence rather than from policy.

Per-engagement consent is captured before any pull. Every pull runs through a counsel-on-record row in the audit log against the engagement — not after the fact, not retroactively. If a member of your firm has not been granted access to a client, they cannot read the client; if a member no longer works for the firm, their FirmMember row is the gate that closes access without any data migration.

Taxerity.AI does not sign or file a return, provide professional approval, or replace the practitioner’s judgment. Circular 230 and other professional obligations remain with the practitioner.

Applicable tax-privacy and security requirements depend on the firm, deployment, and service terms. The application exposes selected code paths for access checks, sensitive-field handling, and audit events; qualified advisers must determine whether those controls are sufficient for a proposed use.

Implementation evidence includes better-auth session and role checks, firm-scoped queries, selected encryption helpers, and DataAccessAuditEvent records. Availability, configuration, coverage, retention, and certification status must be verified separately.

The product does not represent these implementation details as an independent attestation, legal conclusion, or clearance for real taxpayer data.

Taxerity.AI's incident posture centres on four observable controls. First, encryption-key rotation is admin-only and audit-logged: rotating the active key writes a successor EncryptionKey row, stamps the predecessor supersededAt=now(), and emits a DataAccessAuditEvent of kind EXPORT against the encryption_key resource so the rotation itself is recoverable on request. Second, every read/write/delete of a sensitive client record runs through auditFn() in the dataset's resource route, producing a DataAccessAuditEvent row that captures who looked at which client row, when, and against which resource — recoverable as evidence under exam or state-board review.

Third, every taxpayer-data handler scopes by firmId through requireFirmMember (Phase 5 hardening) — userId-only scoping is replaced by FirmMember.userId resolution so a user who leaves one firm cannot keep reading through a stale cookies or URL. Section 7216 acknowledgement toggles on FirmConsent row are audit-logged; the resolution of a portal token is the source-of-truth for which client it serves, never the request body's stock clientId. Fourth, the soft-archive chain delivers the deletion-and-retention evidence a departing engagement can be examined against: the DELETE handler on /api/clients/[id] stamps Client.archivedAt, revokes any active ClientPortalToken row in one transaction, and emits a DELETE-class audit row carrying the revoked-token count. A follow-up shred cron will hard-delete rows whose archivedAt is older than 30 days AND shred UploadedDocument.extractedData / Communication.body for the same client+firm before the table can be cross-joined.

Fifth, there is a support contact for reported incidents: mail the team and the operator can triage against available access-audit records. Key rotation and admin-role events are observable application paths; monitoring, response times, and service-level commitments require separate operational review.

Tracked ownership items include MFA wiring, key-management choices, coverage of sensitive fields, penetration testing, and any external security attestation. These remain open until the responsible owner or assessor records evidence.

If a real incident is observed — a stolen session, a leaked credential, or a suspicious access row — contact the team immediately. Do not treat this page as a guarantee about response time, certification, or clearance for real taxpayer data.