Security model

LendEasy’s security posture is not one product feature — it is the same small set of mechanisms applied at every surface of the platform: isolate the tenant, demand the exact permission, never hold raw secrets, freeze every consequential change behind a second decision, and keep records that prove what happened. This page is the rollup; each section links to the deep-dive guide where the mechanism is specified.

Tenancy & environments

Sandbox and Production are fully separate: they share no credentials, IDs, idempotency records, customer data, provider configuration, signing secrets, or generated artifacts, and a token issued for one environment is rejected by the other. Within an environment, every call names its tenant with the LendEasy-Tenant header — the header selects, the token authorizes — and a resource from another tenant behaves as unavailable, so cross-tenant probing yields nothing. Sandbox preserves the implemented Production contract while simulating only external effects, so controls are exercised before promotion rather than discovered after it.

See Environments & base URLs.

Authentication & authorization

Machine access uses OAuth 2.0 client credentials, with each credential bound to one tenant and one environment and each workload given its own least-privilege client. Scopes establish the broad surface; the decisive check is the exact named permission on every endpoint — a token can carry lending:write and still lack APPROVE_LMS_FUNDING. Authorization is evaluated in layers — environment-valid token, tenant isolation, scope, exact permission, resource visibility, field sensitivity, case context where required, and maker-checker — and failure at any layer denies the operation. A broader scope never fills a missing permission, and human servicing mutations must additionally carry a valid open-case reference that establishes the actor’s relationship to the work.

See Authentication and Access control & maker-checker.

Data protection

Sensitive values are kept out of reach by construction, not by filtering:

• Tokenized instruments. Payment instruments accept a provider vault token — never a raw account or card number. Raw numbers are never stored, so no route can leak them; ordinary reads return masked metadata only. See Payment instruments.
• Masked identifiers. Government identifiers are supplied once at write time, normalized, and never echoed back — not in command records, history events, or logs. Ordinary reads return the type, mask, and lifecycle state only. See Customer identifiers.
• Audited sensitive reads. Complete values live behind dedicated /sensitive routes that require the ordinary read permission and an additional _SENSITIVE permission. Every sensitive read is audited and served no-store, and exact-match lookup answers with masked summaries without revealing whether hidden matches exist. See Access control.
• Scan-gated documents. Uploaded document bytes are not downloadable until a malware scan returns clean; rejected content is quarantined and deleted while the record remains as evidence. Downloads re-verify the stored checksum so corruption is detected rather than delivered. See Documents.
• Per-form derived permissions. Publishing a form definition auto-registers READ_LMS_FORM_<KEY>, WRITE_LMS_FORM_<KEY>, and DELETE_LMS_FORM_<KEY> from the form key, so each form’s entries are grantable independently rather than through one blanket forms permission. See Forms.

Change governance

Consequential change moves through governed commands with second-person control. Native maker-checker parks a flagged command instead of executing it — payload frozen in the checker inbox — and a different actor decides; the maker can never be the checker, and the same separation recurs in dedicated flows such as funding approval and reschedule decisions. Every governed command execution writes a governance record capturing the permission code, route, actor class, and case or system context. Durable records are append-only: corrections and supersessions add records rather than editing originals, and reconciliation repairs go through the owning domain against the authoritative source, never by editing a read model to match an expectation.

See Access control & maker-checker and Reconciliation & drift.

Evidence & audit

The evidence graph links source signals, cases, fact sets, rule versions, decisions, approvals, executions, acknowledgements, and reconciliation outcomes through explicit IDs and hashes — temporal proximity is never treated as causation. Decision records name the exact facts, sources, freshness, and rule versions behind each outcome, and approvals preserve actor, decision, reason, request hash, and separation-of-duties result. The record set is tamper-evident: durable records carry canonical content digests, and evidence packages include a manifest of record IDs, versions, artifact SHA-256 values, and a package digest, so any changed or missing item breaks verification. Audited evidence exports reconstruct the causal record per case or per customer as point-in-time examination bundles, without silently including restricted documents the requesting actor cannot read.

See Evidence graph.

AI oversight

AI work is subject to the same actor discipline as everything else. Grounded outputs are reviewed through a dedicated route where a human accepts, edits, rejects, ignores, or escalates — the original output stays immutable beside the reviewed result, and reviewers see cited facts and freshness rather than only polished prose. A suppression control stops AI work by scope — tenant, agent profile, model version, queue, case type, channel, tool, or action — with dispatch checking suppression before starting and active sessions rechecking before every tool call, so the switch takes effect without waiting for sessions to drain. The reviewer permission and the suppression permission are deliberately distinct, and the AI session and its reviewer are always distinct actors.

See Human review & kill switch.