Trust & Security

Our trust posture

Anilize serves licensed mortgage companies, brokers, loan officers, and their realtor partners. Borrower nonpublic personal information collected through the platform is processed solely for the loan-origination workflow each customer directs.

Anilize maintains administrative, technical, and physical safeguards reasonably designed to protect that information consistent with the Gramm-Leach-Bliley Act Safeguards Rule.

Multi-tenant isolation

Every persisted record in the Anilize platform is scoped to a single customer (tenant) and isolated through Postgres row-level security policies enforced inside the database.

Server-side data access binds every read and write to a verified Supabase JWT session, with row-level security policies evaluated inside the database on every query. Application-layer compile-time narrowing prevents app code from issuing unscoped raw SQL.

CI architecture guards reject any pull request that introduces app-level $queryRaw or $executeRaw calls outside the small set of allowlisted infrastructure files.

Encryption

All data in transit uses TLS. Customer data at rest is encrypted by the database provider.

Third-party credentials (Plaid client secrets, Arive API keys, Lob API keys, etc.) are encrypted at the application layer with AES-256-GCM via a dedicated security helper before being written to the credentials table. Decryption happens server-side on demand and never in the browser.

API keys, webhook signing secrets, and other system secrets are stored in the hosting platform's secret store and rotated through documented operational procedures.

Authentication and access control

Authenticated portal sessions use Supabase Auth with the SSR cookie pattern. Auth-sensitive checks happen server-side; cookie-based sessions refresh automatically through the proxy layer.

Role and membership decisions use server-resolved context. Browser code is never trusted for authorization.

Authentication callbacks land on stable owned hosts (portal.anilize.com, admin.anilize.com) before redirect to the appropriate tenant or branded host.

AI governance

Anilize-built AI features run through a documented governance framework. Every AI surface declares the tools it is permitted to invoke through an AiSurfacePolicy and AiToolPermission allowlist. Tool calls outside the allowlist are rejected and recorded in an immutable AiToolPermissionSnapshot.

AI agent runs are metered, audited, and rate-limited. Tool-permission failures, regulated-boundary failures, and PII-leakage failures are hard release gates for any model promotion.

Anilize does not use customer data to train AI models without an executed Training Consent Form covering the specific tenant scope and data categories. Public-corpus training data passes a separate review and trust-policy gate.

PII detection and redaction run on every dataset that enters a training pipeline, using a Presidio-based detector tuned for mortgage-domain identifiers (SSN, driver license, bank account, NMLS).

Compliance boundaries

Anilize implements deterministic compliance boundary controls covering adverse-action reason codes (Regulation B / ECOA Appendix C, FCRA), fair-lending protected-class signal detection, and valuation boundary controls (AVM / UCDP, appraiser independence). Boundary detections are written to an immutable audit log.

Anilize does not produce or substitute for a Fair Credit Reporting Act 'consumer report'. Plaid-derived borrower data is used inside the loan-origination workflow only.

Audit trail

Anilize maintains an immutable application audit log indexed by company, event type, and timestamp. AI agent runs, tool-permission decisions, retrieval events, compliance boundary detections, and access-lifecycle events are recorded with metadata sufficient to support compliance review.

Audit log entries are retained per the Anilize retention policy (typically 90 days, then aggregated). Usage events are retained for 365 days, then aggregated.

Observability and incident response

Application errors are captured by Sentry with PII redaction policies enforced at the package level. Structured logs flow to Better Stack for retention and search. Production deploys go through Vercel with deployment-attached release identifiers.

Anilize maintains a documented incident-response process. Personal information breaches are reported to affected customers without undue delay and in any event within 72 hours of awareness, consistent with the Data Processing Addendum at /legal/dpa.

Subprocessors

Anilize uses trusted subprocessors to deliver the platform. The complete list is published at /legal/subprocessors and is updated as the vendor footprint changes.

Each subprocessor is bound by data-protection obligations no less protective than those in the Anilize Data Processing Addendum.

Vulnerability disclosure

Vulnerability reports may be submitted to security@anilize.com. Anilize will acknowledge submissions promptly and coordinate disclosure where appropriate. The canonical security contact is published at /.well-known/security.txt per RFC 9116.