TPRM in the AI Era: Third-Party Risk Management When the Connection Is the Risk

Third-party risk management (TPRM) is the process of identifying, assessing, and controlling the risk introduced by any external party that touches your data, systems, or operations. That covers SaaS vendors, contractors, managed service providers, resellers, and the applications those parties connect into your environment.

The reason the discipline is being rethought is structural, not fashionable. A decade ago a third party held your data in their environment, so due diligence on their environment was a fair proxy for your risk. Today a third party holds a live token into your environment. The vendor's own posture still matters. The immediate exposure is the standing authority you granted them, which keeps working whether or not anyone is watching it.

The Salesloft Drift compromise is the clearest recent example. Attackers used stolen integration tokens from one trusted vendor to reach Salesforce data across hundreds of downstream customers. No customer credential was phished. The integration was already trusted, so the activity looked like the integration. Our breakdown of the UNC6395 Salesloft campaign walks through the mechanics, and the Klue and Salesforce supply-chain attack shows the same pattern repeating with a different vendor.

Three disciplines get mixed together in this space, and they answer different questions.

A useful decision rule: if the answer changes when a vendor is breached rather than when their invoice changes, it belongs in TPRM.

Vendor risk management is usually the subset of TPRM that covers contracted suppliers. TPRM also has to cover parties you never contracted: the free browser extension an employee installed, the AI note-taker a team authorized with a corporate account. Supply chain risk extends outward to the vendors your vendors use, which is where concentration exposure hides. The SaaS supply chain security page covers how those layers stack from the product side.

Questionnaires describe a vendor at one moment. Integrations create authority that runs continuously. That mismatch is the whole problem.

Here is how it plays out. A vendor completes a security review in the first quarter. Legal signs a data processing agreement. An administrator authorizes the vendor's app, and the consent screen grants read access to mail, files, and directory data. Ten months later that grant is still active. The scope widened during a product update. The employee who authorized it has left. Nothing in the questionnaire process notices any of that, because the questionnaire never described the connection in the first place.

Configuration is not reality. A completed assessment tells you what a vendor claims to do. An OAuth grant tells you what a vendor can do inside your tenant today.

Two further gaps compound it.

Theoretical configuration versus effective authority. Most reviews capture how an integration is set up on paper. What matters is the access that resolves after roles, scopes, sharing rules, and inherited permissions combine. That resolved access is the effective authority, and it is routinely broader than the intake form suggested. Programs that review configuration alone end up ghost chasing: investigating findings that were never exploitable while the connection that mattered sits outside the review.

No accountable owner at runtime. The security team can name the vendor. It often cannot name the human who authorized the token or the business owner responsible for retiring it. When a disclosure lands, the first hour goes to finding out who to ask.

Every mature program we have seen carries the same four gaps. Naming them makes the remediation obvious.

1. Connections nobody procured. Employees authorize apps directly. A department connects a scheduling tool to the calendar system. A developer installs an extension that requests broad page access. None of it enters the vendor register, so none of it gets tiered, reviewed, or offboarded. The discovery problem is the same one described in shadow AI detection: the population you need to govern is larger than the population you know about.

2. Permission drift after onboarding. The integration you approved is not the integration you have. Scopes expand with vendor releases. An admin widens a service account to fix a broken sync and never narrows it. Drift is silent because nothing re-triggers review.

3. Dormant access from vendors nobody uses. A pilot ended. The contract lapsed. The token did not. Dormant integrations are attractive to attackers precisely because nobody monitors traffic that nobody expects. The OAuth grants that survive offboarding shows how common this is and why the identity provider cannot see it.

4. Embedded AI with delegated authority. This is the blind spot no questionnaire asks about. Third-party applications now ship agents and assistants that act on your data. Many run on the creator's credentials. A user with no access to a restricted object can invoke the agent, and the agent retrieves the data at the creator's privilege level. Your access controls were not defeated. They were bypassed by design. That mechanism is covered in AI agent privilege escalation, and the program-level response in governing AI usage inside third-party apps. Add action chaining, where an agent sequences calls across several connected apps, and the blast radius compounds at each hop. Orphaned agents whose creators have been deactivated keep running with inherited authority.

A complete assessment has two halves. Most programs only do the first one well.

The vendor half:

• Data types processed, residency, and retention
• Access model at the vendor: who can reach customer data, under what approval
• Incident response commitments and notification timelines, in hours
• Subprocessors and fourth-party dependencies
• Independent audit evidence, with the scope checked against the feature you are buying

The connection half, which is usually missing:

• The exact OAuth scopes, API keys, and service accounts requested
• The authorizing identity and a named accountable owner
• Which applications and sensitive data objects the integration can reach
• Whether authentication uses fixed credentials or per-user delegation
• Whether the product includes AI features or agents that act on your data, and whose privileges those agents run with
• Offboarding steps: which tokens get revoked, by whom, verified how

The common mistake is approving a vendor at the entity level and never re-approving the technical grant. Approve the connection, not just the company. The step-by-step version of this, with tiering and the agent question set, is in how to run a vendor risk assessment.

A working TPRM framework then has seven parts, and the structure will be familiar from any recognized risk guidance. What has changed is that each part has to extend to integrations and agents.

1. Inventory. Every third party and every connection, including the ones procurement never saw.
2. Tiering. Criticality based on data sensitivity, effective authority, and business dependency. Not spend.
3. Due diligence. Depth scaled to tier rather than applied uniformly.
4. Contractual controls. Security terms, notification, audit rights, and now AI usage terms.
5. Continuous monitoring. Drift detection, dormancy detection, anomalous access.
6. Issue management. Findings with owners, severity, and remediation dates.
7. Evidence and reporting. Audit-ready records and board-level summaries produced as exports, not projects.

On cadence: reassess on a tiered schedule, and let event triggers override the calendar. Critical vendors annually is a reasonable baseline. Reassess immediately when the integration's scopes change, the vendor discloses an incident or a subprocessor change, the authorizing employee leaves, or the vendor adds AI features that act on your data. That last trigger is the active one right now.

Dynamic TPRM keeps the vendor lifecycle intact and adds a continuous layer that watches the connection. The unit of analysis shifts from the vendor to the grant. Four things run all the time: discovery of connected apps and non-human identities, attribution of each connection to an authorizing identity and an owner, reach mapping across applications and data, and prioritization by toxic combination. One medium finding rarely matters. A dormant integration with broad write scopes, authorized by a disabled account, reaching a system of record, is critical. Combination scoring is what makes the queue workable.

Sequence matters when you build this, because programs stall when policy is written before inventory exists. There is nothing to enforce against.

1. Reconcile the vendor register against the actual connected applications, OAuth grants, and service accounts. Expect the technical list to be much longer.
2. Tier by data sensitivity and effective authority.
3. Assign a business owner and an authorizing identity to every connection.
4. Approve the grant with defined scopes and an expiry, not just the vendor.
5. Turn on continuous monitoring for drift, dormancy, and new unsanctioned connections.
6. Prioritize by toxic combination, then remediate: revoke, narrow, or require re-approval.
7. Add enforcement where the risk justifies it: block, warn, or require approval on high-risk actions.
8. Produce evidence continuously.

The signals worth monitoring, in rough order of value: scope changes on existing grants, new integrations authorized outside the approval process, integrations with zero activity for a defined window, authorizing accounts that have since been disabled, and agent activity inside third-party apps (who invoked it, what identity it used, what data it touched). Ratings feeds and breach alerts are context. They describe the vendor's exterior, not what a token did inside your tenant.

Most of the non-human identities in this picture, service accounts, API keys, and agent credentials, need a lifecycle of their own. Non-human identity management for AI agents covers that lifecycle, and machine identity covers why these identities outnumber and outlast the people who created them.

A maturity ladder, for placing your own program:

• Level 1, Reactive. Spreadsheet register, annual questionnaires, no technical inventory.
• Level 2, Documented. Tiering, an intake workflow, contractual security terms.
• Level 3, Instrumented. Continuous discovery of connections, ownership attribution, drift alerts.
• Level 4, Controlled. Toxic-combination prioritization, automated revocation of dormant access, deterministic guardrails on high-risk actions.
• Level 5, Assured. Runtime evidence for every third-party action, including agent activity, with audit-ready reporting on demand.

Most programs we talk to sit at level 2 and believe they are at level 3, because they have a vendor list and mistake it for a connection inventory.

TPRM tooling is rarely list-priced, so evaluate by what each category can and cannot see rather than by feature count. Three categories dominate, and most enterprises end up needing two of them.

The evaluation questions that separate the third category from a dashboard:

• Does it discover connections that were never registered, or only enrich the ones you tell it about?
• Does it resolve effective access per grant, or read configuration?
• Can it attribute every connection to the human who authorized it?
• Does it cover non-human identities and AI agents, or stop at OAuth apps?
• When a vendor discloses a breach, can it tell you in one query which of that vendor's tokens touched what, and let you revoke from the same place?

Obsidian sits in that third category. It gives security and GRC teams runtime truth about third-party access, which is the half of TPRM that questionnaires cannot cover, and nothing sits in the data path. It maintains a continuous inventory of every SaaS integration across core applications such as Salesforce, Microsoft 365, and Google Workspace: OAuth apps, API keys, service accounts, and shadow integrations, with who authorized each, what permissions it holds, and what data it can reach. It detects token abuse, malicious OAuth grants, and supply-chain threats early from behavioral context in the Obsidian Knowledge Graph, and it gives one-click impact analysis when an industry-wide breach lands, so the question "were we affected, through which tokens, reaching what" is answered from one place with revocation alongside it.

The differentiator is effective authority. Most reviews stop at theoretical configuration, meaning how a connection or agent was set up. Obsidian correlates that configuration with identity context and real behavior inside the application, which is how a maker-mode agent handing restricted records to an unauthorized invoker becomes visible at all. The product background is in introducing Obsidian integration risk management, and the token-level attack path in the new attack surface: OAuth token abuse.