Access control & maker-checker

Authorize each call through tenant, OAuth scope, exact named permission, resource visibility, sensitivity, case authority, and separation of duties—then preserve the decision with the result.

Authentication identifies a client. Authorization decides whether that client may perform this operation on this resource now.

Evaluation layers

valid environment-specific token
  ∩ tenant isolation
  ∩ OAuth surface scope
  ∩ exact endpoint permission
  ∩ resource / legal-entity visibility
  ∩ field sensitivity
  ∩ case authority
  ∩ maker-checker approval
= authorized request

Failure at any layer denies the operation. A broader scope never fills a missing named permission.

Named endpoint permissions

Every operation requires an exact UPPER_SNAKE permission code, displayed on its API page — CREATE_LMS_CUSTOMER, APPLY_LMS_RESTRICTION, READ_LMS_LOAN_SUMMARY, APPROVE_LMS_FUNDING. Read operations alternatively accept the read-superuser permission ALL_FUNCTIONS_READ; no write ever does. Roles aggregate permissions for job functions; integrations receive dedicated least-privilege roles rather than shared administrator credentials.

Client	Illustrative permissions	Excluded authority
Borrower portal backend	`READ_LMS_CUSTOMER`, `READ_LMS_LOAN_SUMMARY`, `CREATE_LMS_PAYMENT`	Product admin, approval, sensitive reads.
Servicing workspace	Case/task/interaction permissions, `READ_LMS_LOAN_SUMMARY`, `APPLY_LMS_RESTRICTION`	Direct raw ledger commands.
Payment integration	`CREATE_LMS_PAYMENT`, `READ_LMS_PAYMENT`, `READ_LMS_RECONCILIATION`	Loan modification and customer-document access.
Funding approver	`READ_LMS_FUNDING`, `APPROVE_LMS_FUNDING`	Creating and approving the same funding.
Reporting pipeline	`ALL_FUNCTIONS_READ` or named report reads	Operational mutation.

Form permissions are derived, not hand-assigned codes from a fixed catalog: 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.

Public API boundary

The public contract exposes normalized customer-facing and lender-integration operations. Internal orchestration, provider callbacks, maintenance, database access, and raw credential/identifier retrieval are not public endpoints. Ordinary reads are masked; the public API never returns raw payment credentials or vault-tokenized government identifier values outside the audited sensitive routes.

Sensitive reads

Complete identifier values, raw contact values, and vault token references live behind dedicated /sensitive routes that require the ordinary read permission and an additional _SENSITIVE permission — for example READ_LMS_CUSTOMER & READ_LMS_CUSTOMER_SENSITIVE. Every sensitive read is audited, and the response is served with no-store so it is never cached. Search and list endpoints do not reveal hidden content through snippets or counts, and AI work packets receive only the subset their task and policy permit.

Case authority

When case management is enabled, human servicing mutations — governed commands, restrictions, autopay changes — carry an open case reference in the LendEasy-Case header:

LendEasy-Case: case_HBR_COL_51

The platform verifies the actor’s authority over that case in order: case owner, then an active task assignment on the case, then a scoped override. A call without a valid case, or by an actor with none of the three, is rejected. Automation never sends the header; its context is recorded from the triggering system. The header is authority context for a permitted operation — it never turns a prohibited command into an allowed one.

Maker-checker

Second-person control is native maker-checker: a flagged governed command parks instead of executing, and a different checker decides through the /v1/makercheckers inbox.

LifecycleGoverned command under maker-checker

SUBMITTEDcommand received with case authority; governance record opened

PARKEDmaker-checker flags the command; payload frozen in the checker inbox

APPROVEDa different checker approves via POST /v1/makercheckers/{auditId}?command=approve

EXECUTEDthe original command runs and the governance record completes

PARKED→REJECTEDchecker rejects; reviewer and decision preserved

The maker can never be the checker, and the checker must hold the command’s checker permission. The same separation recurs elsewhere in dedicated flows: a funding’s creator cannot approve it, and a reschedule request is applied only when a different user approves it through the reschedule decision route. Approval authorizes execution; it does not guarantee a rail or downstream dependency will accept the result.

Service accounts

Each workload uses a distinct client with owner, environment, purpose, scopes, permissions, rotation policy, network controls where configured, and monitored usage. Human attribution is carried separately from the OAuth client when a backend acts for an authenticated operator.

Audit

Authorization decisions link client, actor, tenant, permission, resource, case context, approval, result, and time. Every governed command execution also writes a governance record — readable per loan or customer via the governance-records routes — capturing the permission code, route, actor class, and case or system context. A 403 is not retriable; change the assigned authority through governed administration.

Never solve an authorization failure by granting a general administrator role to an application. Add the minimum named permission after reviewing the resource and action scope.