Third-party risk in the AI era: Why traditional approaches fall short

Reading Time: 8 minutes

Most organizations have a third-party risk management (TPRM) program. Yet few can confidently define a third party now that AI is embedded in business tools. The answer extends beyond vendors to the models, code, and integrations behind the products companies use.

Agentic AI and interconnected ecosystems are reshaping the software supply chain, while offensive AI is lowering the time and cost of exploitation. In a 2026 study by Quantro Security, autonomous AI agents produced verified proof-of-concept exploits for 72% of 3,029 disclosed vulnerabilities, with a median of just 11 minutes and $2.83 per exploit.

Third-party exposure is rising. According to the Verizon 2026 Data Breach Investigations Report, 48% of breaches now involve a third party, up from 30% the year before.

As AI adoption accelerates, organizations need to understand not only who they do business with, but also the datasets and dependencies that support those relationships.

When vulnerabilities can be weaponized in minutes, periodic assessments are no longer enough. TPRM needs to shift to continuous visibility and oversight.

How traditional TPRM works, and where it breaks down

TPRM programs were built around known vendors and suppliers. Those partners were easy to track because they passed through procurement, legal, and security review processes. This framework breaks down in two ways:

First, many programs rely heavily on point-in-time assessments. A vendor completes a questionnaire during onboarding, confirms its controls, and isn’t reviewed again until the contract is up for renewal. That may satisfy compliance, but it reveals little about risk.

Second, organizations often treat all suppliers the same, regardless of risk level. Applying a one-size-fits-all scorecard creates operational friction. Low-risk vendors face complex, irrelevant questions that delay onboarding. Meanwhile, critical providers don’t get the due diligence they need because the scorecard lacks technical depth.

Together, these practices create a “checkbox compliance” mentality that doesn’t support security. You get a clean audit report but little visibility into evolving vulnerabilities. That’s a dangerous blind spot, as threat actors actively seek to exploit trusted vendors.

Attackers are following trust

At Black Hat USA 2026, Microsoft Security leaders Aarti Borkar and Tanmay Ganacharya pointed out that adversaries are no longer just looking for software vulnerabilities; they’re mapping trust paths.

Their session covered a series of software supply chain attacks tracked by Microsoft Threat Intelligence. The incidents included a nation-state compromise of a widely used npm package, credential theft campaigns hidden in open-source repositories, typosquatting operations, and dependency confusion attacks targeting enterprise environments. While the methods used varied, the objective was the same: compromise a trusted component and use that trust to reach downstream victims and scale the impact.

The 2024 XZ Utils compromise illustrates how patient threat actors can be. Operating as “Jia Tan,” an attacker spent two years earning the trust of an overworked maintainer of a critical open-source library, then inserted a backdoor that could have provided remote access to affected systems. An engineer uncovered it by chance while investigating a slight delay in system logins.

Supply chain compromises are hard to catch because they look legitimate. IBM’s Cost of a Data Breach Report 2026 puts the average time to identify and contain these attacks at 258 days.

Even signed provenance can’t be taken at face value. In May 2026, the “Mini Shai-Hulud” worm, attributed to the threat actor TeamPCP, compromised over 170 npm and PyPI packages used by major enterprise and AI platforms. These malicious packages shipped with valid, cryptographically signed attestations. The technical paperwork checked out, but the underlying software was malicious.

A static TPRM questionnaire can fail the same way. It shows what a vendor attested to, not whether its environment has been compromised since.

Adversaries have realized a simple truth: they don’t need to break into your network when they can use what you already trust.

What counts as a third party today

The biggest challenge is identifying the hidden dependencies that make up the modern digital supply chain.

Third parties now include:

• Foundation model and API providers
• AI features embedded in existing SaaS tools
• AI agents acting on an organization’s behalf
• Open-source maintainers and dependencies
• Cloud, data, and managed service providers
• Fourth parties and beyond

Many of these dependencies never pass through procurement or formal vendor risk review. Even well-vetted suppliers may add AI capabilities through product updates, embedded copilots, or new integrations without triggering a new assessment.

Visibility gaps are common. SecurityScorecard’s 2026 Supply Chain Cybersecurity Trends Report found that 78% of organizations say their cybersecurity programs cover less than half of their vendor ecosystem.

AI is also widening the circle internally. Citizen developers, such as product managers and analysts using low-code tools and AI assistants, now build business applications and expand the shadow software supply chain.

The line between internal and external code is blurring, which raises a practical question: How do you trust a change to production when no one on your security team has read the code?

AI agents are third parties with your keys

Unlike most third parties, an AI agent acts inside your environment. A SaaS vendor holds your data; an agent uses your access, under credentials you issued and a model you don’t control. That changes the risk in three ways:

• An agent’s behavior isn’t fixed at onboarding. Swap the model, prompt, or tools, and it’s effectively a new agent. Nothing triggers a procurement review.
• Everything it reads is an input. Prompt injection can turn a partner’s document or an inbound email into an instruction.
• It’s built to finish the task. Blocked by a control, it may try another route that looks like legitimate activity.

Vendor reviews need new AI questions

Organizations often assess the AI tool itself but not the ecosystem behind it, and standard vendor questionnaires rarely ask what matters most:

• What model underpins your AI, and how are upstream dependencies managed?
• What are the data boundaries? Can this model ingest or train on our sensitive inputs?
• Where did the training data originate, and how do you protect against data poisoning?
• Who governs model updates, and how do you detect silent model drift or unauthorized swaps?
• How do you secure your API connections and prevent prompt injection or output manipulation?
• What is the failover plan if a critical foundation model provider experiences a major outage or breach?

The future of TPRM is continuous visibility

Managing third-party risk is an ongoing process, not an annual exercise. Mature programs apply zero trust principles to the vendor ecosystem: trust is verified continuously rather than granted once at signature.

“Continuous” doesn’t mean real-time for every vendor. It means events, not the renewal calendar, determine how quickly you learn that a vendor’s risk has changed. Achieving that level of visibility depends on four practices:

1. Tier first. Rank vendors by business criticality and the systems and data they can reach. Critical vendors get full monitoring; the long tail gets a lightweight baseline.
2. Reassess on events, not dates. Reopen the questionnaire when something material changes: a breach, a critical vulnerability in a shipped component, a new AI feature or swapped model, a new sub-processor, or an acquisition.
3. Include notice in the contract. Require breach notification on a defined clock and notice of sub-processor, model, or integration changes. Without the clause, you won’t hear about them.
4. Watch vendor activity in your environment. Vendors reach your systems through identities: service accounts, API keys, OAuth grants. Compare logged activity against what was granted and alert on the gap. It’s the one continuous signal most organizations already own.

Two things hold this together: a dependency map of which processes rely on which providers, and a containment plan for every critical vendor. Visibility only matters when it drives action.

Extend traceability to the AI layer with SBOMs and AIBOMs

For deeper visibility, leading organizations are pushing beyond vendor attestations and requiring traceability. For standard software, that means a Software Bill of Materials (SBOM) and signed, verifiable builds, guided by frameworks like NIST’s Secure Software Development Framework (SP 800-218), CISA’s 2026 Minimum Elements for a Software Bill of Materials, and Supply-chain Levels for Software Artifacts (SLSA). Signed provenance is a baseline, not proof of safety, as Mini Shai-Hulud showed, so pair it with continuous monitoring.

Traditional SBOMs don’t capture AI-specific risk, so procurement teams are adding an AI Bill of Materials (AIBOM). An AIBOM documents the underlying architecture of a vendor’s AI systems. Emerging guidance from the OWASP AIBOM Initiative and standardized formats such as CycloneDX are helping shape how these inventories are created and shared. AIBOMs can include base foundation models, dataset provenance, fine-tuning lineages, and embedded runtime guardrails.

Joint guidance from CISA and G7 partners, Software Bill of Materials for AI – Minimum Elements, extends SBOM practices to AI systems. If a vendor can’t provide a clear registry of what sits inside its models and datasets, that’s a signal to limit the data it can access.

What to prioritize now

You don’t have to rebuild your TPRM program all at once. These steps offer a starting point:

• Inventory third-party dependencies. Catalog every vendor relationship, including AI services and open-source components.
• Tier vendors and reassess on events. Scale due diligence to criticality and access, and reopen reviews when risk changes.
• Demand software and AI transparency. Require SBOMs and AIBOMs from critical vendors.
• Review data-sharing practices. Audit which datasets your external AI tools and models can access.
• Govern business-led AI and development. Require risk reviews for tools and code introduced by business teams and citizen developers before they touch sensitive corporate data.
• Treat AI agents as non-human identities. Give each an owner, a least-privilege scope, execution logging against its assigned task, and a defined revocation trigger.
• Update incident response plans. Include third parties in tabletop exercises. Plan on the assumption that a supplier will eventually be compromised, using scoped access and segmentation to limit the impact.

Third-party risk is a resilience challenge

This doesn’t mean slowing innovation. However, as offensive capability becomes easier to scale, you need to understand the trust paths adversaries can abuse before they become open doors.

Extending the rigor you apply to known vendors to the technologies, services, and components you don’t fully control can help your organization adopt AI securely and limit disruption across the digital supply chain.

How SHI can help modernize your approach to third-party risk

SHI helps you move TPRM from periodic assessments to continuous visibility. We partner with you to:

• Assess cybersecurity and risk management maturity
• Align your security and TPRM programs with industry standards and frameworks
• Identify hidden dependencies across software, cloud, SaaS, and AI ecosystems
• Evaluate governance, identity, and data protection controls
• Build defense-in-depth strategies that improve resilience

Whether you’re evaluating AI solutions, onboarding vendors, or modernizing your program, we help you understand where risk exists, prioritize remediation, and adapt as your third-party ecosystem changes.

NEXT STEPS

Ready to see where your TPRM program stands?

Speak with an SHI expert to schedule a Third-Party Risk Assessment.