The limited role a lending platform plays when it connects users without taking custody of funds or guaranteeing repayment. This matters because the platform’s legal and operational responsibilities can be narrower than users expect. When intermediation boundaries are unclear, compliance failures and user losses become more likely.
Expanded Definition
Platform intermediation describes an arrangement where a lending platform connects borrowers and lenders, or users and counterparties, without itself taking custody of funds or promising repayment. In practice, the distinction matters because the platform may be acting as a technical matchmaker, a workflow orchestrator, or a regulated financial intermediary depending on how it routes transactions and disclosures.
Definitions vary across vendors, regulators, and product teams, so the term should be read in context rather than assumed to have one fixed legal meaning. In NHI and IAM terms, the same boundary problem appears when an AI agent, service account, or delegated workflow is permitted to initiate actions without becoming the owner of the underlying asset or obligation. That is why control boundaries, authorization scopes, and auditability are as important as the user-facing product description. The NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful here because it frames accountability, access control, and system integrity in ways that map well to intermediary platforms. The most common misapplication is treating a routing platform as if it were a principal, which occurs when legal responsibility, operational control, and transaction custody are blurred into one role.
Examples and Use Cases
Implementing platform intermediation rigorously often introduces product and compliance constraints, requiring organisations to weigh user convenience against the cost of tighter disclosures, stronger controls, and more explicit role separation.
- A lending marketplace matches borrowers with lenders but does not hold deposits, so its obligations focus on identity verification, disclosures, and transaction routing rather than custody.
- An embedded finance platform passes payment instructions to a regulated partner while the partner executes settlement, creating a clear separation between interface ownership and financial responsibility.
- A workflow system in which a service account submits loan-related requests on behalf of users needs strict authorization boundaries so the platform cannot be mistaken for the decision-maker or fund holder.
- The New York Times breach illustrates how identity and privilege boundaries matter when a platform or connected system is compromised and downstream users expect protections the intermediary may not actually provide.
- Teams can use the Ultimate Guide to NHIs to evaluate whether platform automation is operating as a bounded intermediary or as an overprivileged actor with too much reach.
Why It Matters in NHI Security
Platform intermediation is relevant to NHI security because the same systems that connect parties often rely on API keys, service accounts, and delegated workflows to do the connecting. If those NHIs are overprivileged, poorly segmented, or assumed to carry responsibilities they do not actually have, the organisation can misstate accountability and misconfigure controls. NHIMG research shows that 97% of NHIs carry excessive privileges, which is especially dangerous when an intermediary platform is treated as harmless middleware instead of a sensitive trust boundary. That pattern also helps explain why so many organisations miss the real attack surface until a breach or dispute forces a closer review of who could do what, on whose behalf, and with which credentials.
This concept becomes operationally important when incident response, user complaints, or regulator inquiries reveal that the platform never owned the funds, never guaranteed performance, and still had enough access to trigger material harm. Organisations typically encounter the need to redraw intermediation boundaries only after a failure or dispute, at which point platform intermediation becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Intermediaries need least privilege and explicit access boundaries. |
| NIST SP 800-63 | Identity assurance is relevant where a platform brokers user actions. | |
| NIST Zero Trust (SP 800-207) | RA-3 | Zero trust requires each intermediary action to be explicitly authorized. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Overprivileged NHIs often sit inside intermediary platforms. |
| NIST AI RMF | GV-2 | AI-mediated intermediaries need clear governance and accountability. |
Verify delegated actions with appropriate identity assurance before allowing sensitive transactions.
Related resources from NHI Mgmt Group
- How should security teams govern AI platform access from day one?
- When does a cloud identity platform create more governance risk than it reduces?
- Should organisations consolidate secret management and privileged access into one platform?
- How should security teams decide between native ERP controls and a separate governance platform?
