Access Control Policy

This policy describes how access to SendTax systems and customer data is granted, used, reviewed, and revoked. It applies to:

• Customers (filers and tax-professional firms) accessing their own data through the SendTax product.
• Internal staff (employees and contractors of Howell & Gibbs LLC) accessing SendTax systems in the course of building and operating the service.

This document is a companion to our Information Security policy. Items marked Roadmap are not yet in production.

---

1. Guiding principles

1. Least privilege. Every account — customer, employee, or service — receives only the access required for its purpose, and no more.
2. Defense in depth. Authorization is enforced at multiple layers: identity provider, application code, and database (Row-Level Security). No single layer is solely responsible for keeping data isolated.
3. Default deny. New roles, new tables, and new endpoints start with no access. Permissions are added deliberately, not removed reactively.
4. Auditability. Sensitive actions are logged with the identity of the actor, the affected resource, and the time. Access decisions can be reconstructed after the fact.

---

2. Defined roles

SendTax has four primary roles. Each is enforced server-side; client-side controls are treated as user-experience affordances, never as security boundaries.

The Preparer/Viewer distinction is encoded in the tenant_filer_links table in our database; the relationship has an explicit lifecycle (PENDING → ACTIVE → ENDED or SUSPENDED) so access can be cleanly revoked.

Customers (filers and firms) cannot escalate their own role. Administrator access is granted only through a deliberate, logged internal procedure.

---

3. Authentication requirements

All accounts

• Authentication is handled by Clerk (our identity provider) and protected by Clerk's password requirements, breach-password detection, and rate-limiting.
• All authenticated API requests carry a short-lived JWT signed by Clerk and validated server-side on every request.
• Session expiration and refresh are managed by Clerk per environment policy.

Multi-factor authentication

• MFA is available to every SendTax account via Clerk and can be enabled at any time from account settings.
• MFA is enforced for tax-professional firm users — those whose firm role is firm administrator or firm member — and for SendTax administrators. Enforcement is evaluated at sign-in (during the /oidc-login token exchange, not re-checked on every authenticated request) and applies a grace period in which a not-yet-enrolled user is warned and allowed through before sign-in is blocked. (The Preparer / Viewer designations below are per-client access levels, distinct from the firm role that drives MFA.)

Service-to-service authentication

• Internal services authenticate to managed sub-processors using short-lived credentials wherever the provider supports it (e.g. Workload Identity Federation for Google Cloud KMS).
• Long-lived API keys are stored only as encrypted Fly.io secrets, scoped per environment, and never committed to source control. Secrets are rotated when a team member with access offboards or when a leak is suspected.

---

4. Authorization

Customer authorization

Customer authorization is enforced at three layers, in order:

1. Identity provider (Clerk). The request must present a valid, unexpired JWT.
2. Application layer. API endpoints declare which role(s) may invoke them. Internal-only endpoints are guarded by an explicit require_admin dependency that verifies elevated privilege server-side.
3. Database layer (Row-Level Security). Every request sets either app.tenant_id (a firm acting on a filer's behalf) or app.filer_id (a filer acting on their own data). PostgreSQL RLS policies — declared with FORCE ROW LEVEL SECURITY — return only rows the caller is entitled to see. The database itself enforces tenancy, not just the application.

A bug in any single layer does not, by itself, expose another customer's data.

Internal authorization

• Production engineers receive access to internal tools and dashboards scoped to their role.
• Administrator privileges in the application are granted via a deliberate internal procedure (the promote_to_admin operation), which is logged.
• Direct database access (psql, migration runs) is performed from a small number of named operator accounts. The application connects to the database using a separate, non-superuser Postgres role whose privileges are restricted by RLS and grant configuration.

---

5. Customer-managed access

Tax-professional firms control which of their staff can act on a given filer's behalf, and filers can revoke that access.

• A firm establishes a relationship with a filer through an explicit invitation flow that the filer accepts. Until the filer accepts, the link is in PENDING state and the firm has no access to the filer's data.
• Once accepted, the link moves to ACTIVE. The firm may assign each staff member as Preparer (read/write) or Viewer (read-only) for that filer.
• Either party can end the relationship. On termination, the link moves to ENDED and the firm's access — including for staff currently signed in — is revoked on the next authenticated request, because authorization is checked at the database level on every query.
• A SUSPENDED state exists for compliance or billing reasons and produces the same access revocation.

---

6. Account lifecycle

Provisioning

• Filers self-provision by creating an account at sign-up.
• Firm staff are invited by a Firm Administrator within the SendTax Pro application. They receive an email invitation and create their own credentials.
• Internal staff receive accounts at onboarding, with access scoped to the systems required for their role.

Modification

• Customers can change their own profile and credentials.
• Role assignments within a firm (e.g. promoting a Viewer to a Preparer) are made by Firm Administrators in the Pro application.
• Internal role changes require approval from an existing Administrator and are logged.

Deprovisioning

• Customers can delete their SendTax account from account settings. Account deletion triggers a documented data-retention process described in our Privacy Policy.
• Firm staff offboarding is the responsibility of the firm; SendTax provides the controls to remove a staff member from the firm and to revoke all of their filer links.
• Internal-staff offboarding follows a documented checklist that revokes application access, identity-provider access, hosting-provider access, secret-manager access, source-control access, and any shared credentials, on the offboarding date.

---

7. Privileged access

Privileged access — Administrator role in the application, production infrastructure access, and direct database access — is treated as a distinct category with stricter controls.

• The Administrator role is granted to the smallest possible number of internal operators.
• Promotion to Administrator is performed via a deliberate scripted operation, not via UI toggles, so the action is recorded and reviewable.
• Production deploys are performed from a CI pipeline triggered by a reviewed pull request. Ad-hoc production changes are reserved for documented incident response.
• Administrator actions on customer data (e.g. opening a support session) are logged in our audit-log table with the actor, the target resource, and a reason.
• Long-lived shared admin credentials are not permitted. Each operator acts under their own identity.

---

8. Access logging and audit

SendTax maintains a server-side audit log for sensitive actions, including:

• Authentication events (sign-in, sign-out, failed attempts).
• Changes to tenant/filer relationships (link creation, role change, termination).
• Administrative actions (role promotion, support-session access).
• Access to sensitive customer documents and tax-return data.

Audit-log records are append-only, enforced by a database trigger (updates and deletes are rejected), and stored in a dedicated table with hardened write paths. Audit rows are not purged by application code; their retention is an operational commitment aligned with the longest applicable tax-data retention obligation, not a code-enforced floor.

Operational telemetry (errors, latency, request volume) is captured by Sentry and our internal monitoring stack; this telemetry is scrubbed of known sensitive fields before transmission.

---

9. Access review

• Customer-controlled access (firm ↔ filer links) is continuously reviewable by customers themselves from within the Pro and Filer applications.
• Internal access to production systems and Administrator roles is reviewed at least annually, and additionally on any role change or offboarding event. Reviews are documented.
• Establishing a quarterly cadence for internal access reviews, and publishing the review log to our Trust Center summary, is on our roadmap. (Roadmap)

---

10. Device and remote-access requirements for internal staff

• Production access requires a company-managed device with full-disk encryption and an enforced screen-lock timeout.
• Personal accounts are not used for production access; all internal systems are accessed under company-issued identities.
• Remote work is the default; there is no privileged "office network." Access controls do not depend on network location.

---

11. Exceptions

Any deviation from this policy (for example, a temporary grant of elevated access during an incident) requires:

1. Approval from a second internal operator.
2. A documented justification recorded with the change.
3. A scheduled expiration date.

Exceptions are reviewed at the next access review and are not allowed to become permanent without explicit re-authorization.

---

12. Policy review

This policy is reviewed at least annually, and additionally whenever a material change to our authentication, authorization, or organizational structure ships.

Material changes are noted in the version line at the top of this document.

---

13. Contact