Introduction

Since the start of the decade, adversaries from well-funded nation states to common cybercriminals increasingly reach their attack targets via new vectors: vendors, software, and service providers that every modern organization depends on. Recent data from industry reports reinforces this change. Understanding that shift is the first step toward managing it through third-party risk management (TPRM) and ensuring continuous supply-chain ecosystem trust can be achieved.

A decade that began with a wake-up call

When the decade opened, a handful of incidents redefined how leaders think about trust in technology. The compromise of SolarWinds’ Orion application showed that a single trusted software update could quietly open doors inside thousands of organizations at once. The widespread exploitation of Microsoft Exchange servers showed how one flaw in commonly used software could be weaponized on a global scale. The attack on Kaseya VSA proved that compromising one provider of a remote management tool could ripple outward to the many businesses that relied on it.

These events shared a common theme and many lessons to be learned. The fastest way into a well-defended organization is often through a partner that the organization already trusts. Attackers discovered that the way into a well-defended organization was not through the front door, but through a side door; a supplier, software component, or service provider the organization already trusted. That insight has only deepened since. Microsoft specifically calls out more supply chain compromises as an emerging threat from attackers in their 2025 Microsoft Digital Defense Report.

Third-party involvement in breaches and impact on costs are growing exponentially

There’s no doubt enterprise organizations depend highly on global providers and deeply-integrated supply chains to run their businesses and retain much-needed cost, quality and time-to-market competitive advantages. What was once a series of headline incidents has become a measurable, sustained trend. The 2026 Verizon Data Breach Investigations Report found that breaches involving a third party reached 48 percent of all breaches, a 60 percent increase over the prior year. In roughly half of confirmed breaches, someone other than the victim organization played a part in the chain of events.

The significant financial consequences are just as clear. IBM’s Cost of a Data Breach Report 2026 research places the global average cost of a breach at a record $4.99 million, up 12 percent over the prior year. The average cost when the breach involved a supply chain partner increased by over $227 thousand. Not adequately managing third-party risk will likely have measurable financial impacts at the time of bad-day events when there is a data breach.

Attackers are innovating and staying ahead of defenders

The most important development is not simply that third-party attacks are more frequent. They have become more sophisticated in step with the way organizations build and buy technology. As development teams and business users adopt new tools at speed, like GenAI, attackers have followed them into that terrain. Adversaries are moving from smash and grab attacks and looking more like patient investors in future access. Let’s review recent, compelling examples.

Modern applications rely on shared packages that can be installed automatically across many systems and environments. Attacks like the Shai-Hulud ones highlight the weaknesses of identities and account access in the attack vector, and how a self-spreading worm can move through the trusted software package ecosystem to compromise systems and harvest credentials, secrets, and keys at scale. A single poisoned component can create downstream exposure for thousands of organizations.

In the XZ Utils case, an attacker spent years building trust within an open-source community before trying to insert a hidden backdoor into a widely used open-source library. This was a long-term effort to compromise foundational technologies millions of systems rely upon.

The old perimeter walls no longer mark the boundary

For years, organizations defended a clear edge and defensible perimeter. Firewalls, intrusion prevention, and endpoint protection were the organization’s main line of defense. That boundary has shifted. The new perimeter is increasingly defined by identities and the access they hold, not by the network. Trust itself is sought and attached.

Attackers can bypass traditional controls by stealing and abusing access tokens, cloud credentials, application keys, certificates, and other trusted credentials. Because the access can appear legitimate, conventional defenses may see routine activity rather than an intrusion, making detection difficult and giving attackers the time they need to carry out their goals.

Hiding in plain sight

Attackers are also abusing the same legitimate tools that IT teams and MSPs rely on every day. Microsoft in their MDDR found 79% of ransomware cases involved at least one remote monitoring and management tool. Huntress reported in their 2026 Cyber Threat Report that abuse of RMM tools rose a whopping 277 percent year over year and appeared in nearly one-quarter of investigated incidents. Stolen credentials were another major entry point, with suspicious logins representing 37 percent of the identity threats Huntress tracked.

AI is reshaping the types of attack and the organization’s attack surface

AI is changing supply chain risk in two ways. First, attackers are using it to work faster and at greater scale. Google Cloud’s Mandiant research describes a 2025 shift from experimentation to operational use, including adaptive tools that can rewrite code and agents that can navigate systems with limited human oversight.

Second, every supplier’s AI systems and use of AI is now part of an organization’s attack surface, whether it’s visible or not. Providers are rapidly embedding AI into software, digital products, and software, while organizations are connecting those tools to sensitive data and workflows. IBM found a 56 percent increase in AI-generated attacks. More than one in four organizations that experienced a malicious attack reported that it was AI-driven, adding an average of $1 million per breach. IBM also found that 92 percent of organizations reporting an AI-related breach lacked proper AI access controls.

The takeaways

Security and TPRM teams are facing a completely different world compared to the start of the decade. Digital supply chain complexity is no longer just about the ‘third-party.’ It’s forcing teams to look with wider optics across fourth and even nth parties! This complexity is happening against a landscape where supply chain attacks are now systemic; the perimeter has moved toward identity, access and trust, and AI increases both attacker capability and vendor exposure. This is happening at such an increasing speed such that cyber risk and TPRM can no longer be treated as a periodic compliance task across their vendor ecosystem.

Next in the series

Look for part two of the series where I’ll focus on the challenges of managing third-party cyber risk and why the current approaches are not delivering the resilience and ecosystem trust outcomes security and IT leaders must achieve.

What You Need to Know

Today’s AI systems depend on interconnected models, agents, data sources, tools, cloud platforms, and infrastructure providers. A weakness anywhere in that ecosystem can affect the security and reliability of the resulting AI service.

CISOs and AI vendor security leaders should keep these points in mind:

• The threat surface has moved beyond the model

• Agentic AI moves risks into real-world actions

• Untrusted content is a new attack vector

• Identity and accountability break down with autonomous agents

• Third- and nth-party dependencies obscure accountability, so independent assurance matters

Introduction

The AI threat landscape is shifting from attacks against an individual model to attacks against an entire AI operating environment.

The model is only one part of that system. AI systems may also include retrieval databases, persistent memory, autonomous agents, identity services, APIs, external tools, cloud infrastructure, and human approval workflows. AI systems may appear simple, but behind the scenes they are quite complex.

According to the World Economic Forum Global Cybersecurity Outlook 2026, the top three cybersecurity issues related to generative AI from respondents are data leaks, advancement of adversarial capabilities, and technical security of the AI systems themselves. This reflects the growing awareness by organizations of the need for assessing AI security. For security leaders, the central question is therefore no longer simply, “Is the model secure?” It is:

Can I prove that the model, the system in which it operates, and the third parties supporting it are secure?

Emerging Threats to AI Systems

The AI threat landscape is evolving rapidly, making it hard for organizations buying AI technology and AI system vendors to keep pace. These are some of the emerging threats to AI systems we have identified that need to be considered.

1. Training-data, model, retrieval, and memory poisoning through third parties

AI models depend on large collections of training data, fine-tuning data, evaluation sets, retrieved information, and in some cases persistent memory. An attacker who corrupts any of these inputs may be able to influence how the model behaves.

What’s new is that poisoning can enter through third-party datasets, open-source models, fine-tuning services, retrieval systems, knowledge bases, persistent memory, or other components added later in the lifecycle. This requires continuous evaluation of data integrity and provenance across the full AI system, not just the original model.

In retrieval-augmented generation systems, poisoned content can live inside a knowledge base and surface only when a particular query is asked. Because the malicious content lives in the knowledge base rather than the prompt, it can persist across many sessions and users, quietly steering answers, corrupting decisions, or serving as a delivery mechanism for indirect prompt injection.

Memory creates a similar risk. Some agents retain user preferences, prior decisions, or information learned during previous interactions. An attacker may attempt to insert false facts or malicious instructions into memory, causing the agent to reuse poisoned information in future sessions after the original attack has disappeared from view.

The risk is amplified when ingestion pipelines pull from open or loosely governed sources, or when agents can write to memory, retrieval indexes, shared repositories, or other systems that later become trusted context. A single poisoned document, web page, code repository, or email may quietly redirect workflows, leak information repeatedly, or spread corrupted content to other agents and knowledge repositories.

2. Automation of jailbreaks and safety-control circumvention

Jailbreak methods are becoming more automated and sophisticated. They may use long, multi-step conversations, encoded instructions, role-playing scenarios, adversarial suffixes, or instructions hidden in images and documents. Highly capable models may successfully interpret sophisticated or obfuscated attack inputs that less capable models fail to understand, potentially increasing exposure to advanced jailbreak techniques.

The risk becomes significantly greater when a jailbroken model has access to sensitive information, code execution, cloud consoles, communication systems, or physical operations. In those circumstances, safety circumvention can become a security incident rather than a content-moderation failure.

3. Indirect prompt injection

Indirect prompt injection occurs when malicious instructions are embedded in content that an AI agent reads, such as an email, webpage, document, image, calendar invitation, or code repository.

The agent may mistake those instructions for legitimate directions and act on them. For example, manipulated content could attempt to make an agent retrieve sensitive information, alter a workflow, or send data to an external destination. While there is not a large body of public examples, some examples highlight the dangers. For example, a plaintiff in a court case included concealed prompts in court filing documents, instructing any AI model to agree with his position and treat the clerk's previous ruling against him as an error. The most dangerous configuration combines three capabilities:

1. Access to private data
2. Exposure to untrusted content
3. The ability to communicate or act externally

When all three are present, a single poisoned source may provide an attack path from initial manipulation to data exfiltration or unauthorized system activity.

4. Agent identity and excessive agency

Traditional identity and access management (IAM) was built for two kinds of actors: human users and relatively predictable non-human service accounts. Agentic AI does not fit neatly into either category. Within a single workflow, an agent may act on behalf of a specific person in one moment, operate as an automated process, call external tools, and even spawn sub-agents to complete a task.

This creates identity and accountability challenges that conventional IAM controls were not designed to address. When an agent takes an action, it may be difficult to answer questions like:

• Who was the agent acting for?
• What authority was it actually granted, and for what purpose?
• Did it delegate work to another agent or tool, and did that authority expand along the way?
• If something goes wrong, which component in the chain was responsible?

These questions become harder still when agents share broad, long-lived credentials, inherit permissions implicitly, or create sub-agents without clear limits or expiration.

An agent may struggle to distinguish between what a user explicitly requested, what an external document suggested, what another agent delegated, and what a tool claimed was necessary. It may have legitimate authority but use that authority in response to an untrusted or manipulated input. The risk increases when agents use broad, persistent credentials or can create sub-agents without clear limits, making incident investigations particularly challenging.

5. Multi-agent coordination and cascading failures

Organizations are increasingly deploying AI systems composed of multiple AI agents that collaborate, delegate work, and share information. While this approach can improve scalability and specialization, it also introduces new security risks that don’t exist in single-agent architectures.

An attacker who compromises, manipulates, or poisons one agent may be able to influence other agents that trust its outputs. Malicious instructions, false information, or unauthorized actions can propagate through delegation chains, creating cascading failures that become difficult to detect and investigate. Multi-agent environments may also introduce risks such as agent-to-agent prompt injection, unauthorized delegation, agent impersonation, recursive task loops, and excessive resource consumption.

6. Compromised tools, connectors, and agent platforms

Every tool or connector available to an AI system is both a software dependency and a potential source of instructions entering the model’s context. A compromised connector, plugin, API, or MCP server could steal credentials, return manipulated information, inject malicious instructions, or cause an agent to invoke additional compromised services. The resulting risk depends on what the component can access, whether it can modify data or systems, and whether it can communicate externally.

7. Model, dataset, and software supply-chain attacks

A provider that appears to deliver a single AI product may depend on a complex chain of upstream and downstream organizations for third-party models, datasets, embeddings, container images, open-source packages, development frameworks, and hosted services. This leads to a range of threat vectors that include poisoned datasets, backdoored model weights, malicious model files, compromised model repositories, vulnerable inference servers, unsafe agent templates, and malicious software packages.

These nth-party relationships create significant challenges for security leaders. An organization may have contractual and risk-management visibility into its AI system vendor, but little insight into the model provider, hosting environment, data source, or tool developer supporting the vendor’s system.

8. Attacks against compute, orchestration, and cloud environments

AI workloads concentrate valuable data, intellectual property, credentials, and expensive computing resources in shared infrastructure. AI activities happen across a broad range of infrastructure and applications. Attackers may target cloud management interfaces, container environments, workload schedulers, GPU drivers, notebooks, storage systems, or secrets embedded in jobs and container images. Model checkpoints created during training can also become targets because they may contain valuable versions of a model’s capabilities.

AI infrastructure additionally creates opportunities for economic denial-of-service attacks. An attacker may deliberately trigger long reasoning operations, recursive agent loops, repeated tool calls, and GPU-memory exhaustion. A relatively inexpensive request can generate substantial costs across inference services, databases, and external APIs.

A recent example comes is the attack on Hugging Face. They reported that an intrusion into production infrastructure was conducted through an autonomous agent framework, which turned out to be OpenAI testing frontier models. Hugging Face’s data pipeline was abused to run code on a processing worker. The agent then escalated privileges, collected more credentials, and moved to other systems, i.e., classic threat actor tradecraft. The incident highlights several risks associated with AI: the pace of frontier model development and an agent's ability to identify and abuse vulnerabilities and build complex attack chains, and the need for adequate guardrails for agentic systems.

Recommendations for Third-Party Risk Management (TPRM) Teams

The uncomfortable reality is that many companies are adopting AI faster than they're building AI threat and risk expertise. As a result, expecting TPRM to independently assess AI security at a deep technical level is often unrealistic. So how do you get your TPRM program up to AI speed?

1. Establish an AI Security-specific Process
Determine how you are going to assess the security of the AI system that can be done in an efficient, repeatable, and comparable process. The challenge is current assurance instruments aren't fit for purpose because they lack scalability, relevance, and reliability. Using these instruments can introduce more delays and friction into the assessment and procurement process because they can't answer the question of how secure the AI system really is with confidence.

2. Assess the complete AI system
Determine how you are going to assess the security of the AI system that can be done in an efficient, repeatable, and comparable process. The challenge is current assurance instruments aren't fit for purpose because they lack scalability, relevance, and reliability. Using these instruments can introduce more delays and friction into the assessment and procurement process because they can't answer the question of how secure the AI system really is with confidence.

3. Require independent assurance
TPRM functions should establish assurance requirements based on the sensitivity of the data, the autonomy of the system, and the potential impact of its actions.

Recommendations for AI System Vendors

These recommendations apply to the broad ecosystem of model developers, model hosts, cloud providers, AI application vendors, agent-platform developers, connector providers, and data suppliers, all of which could be part of an AI system.

1. Understand and document the AI system
Maintain a clear understanding of how the AI system works, including the organizations, technologies, data sources, and services that support it.

2. Ensure transparency and traceability
Be able to identify where important system components, data, and outputs come from, and how they have changed over time.

3. Limit access and authority
Ensure AI systems have only the access and permissions needed to perform their intended functions, with appropriate oversight for significant actions.

4. Protect information used by the AI system
Safeguard the information, knowledge sources, and records that AI systems rely on to make decisions and take actions.

5. Monitor AI system behavior
Maintain visibility into how AI systems operate, what information they use, the actions they take, and any unusual or unexpected behavior.

6. Evaluate the security of the complete system
Assess the security and resilience of the entire AI system, including people, processes, technologies, data sources, and external dependencies.

3. Provide independent, validated assurance
Support prospects and customer trust through independent assessments, certifications, or other forms of validated assurance.  

Conclusion

AI is rapidly becoming one of the largest sources of third-party risk in the enterprise. Unlike traditional software, AI systems rely on interconnected models, agents, external data sources, retrieval systems, cloud infrastructure, and numerous third- and nth-party providers, making accountability and security more difficult to assess. As a result, vendor questionnaires and legacy assessment approaches are often insufficient to evaluate the true risk of an AI-enabled system. TPRM teams that establish AI-specific assessment requirements and demand independent, validated assurance like HITRUST AI Security will be better positioned to identify hidden risks, accelerate procurement decisions, and protect their organizations from emerging threats that can originate anywhere in the AI supply chain.

Vendors standardizing on HITRUST AI Security can gain a competitive advantage that provides transparency to buyers and enables them to remove time and friction in the procurement process. This makes it easier for buyers to perform their evaluation efficiently and effectively to meet the needs at the speed of their organization.

Take the next step

Reach out today to learn how the HITRUST can help your organization evaluate AI security, validate security controls for current and emerging AI threats, and build trust across ecosystems.

Validated Cybersecurity Assurance: Why a Passed Audit Is Not a Measured Risk

Guest blog by AJ Yawn, Author, GRC engineer at Rippling, and Founder of the GRC Engineering Club

A clean third-party audit report tells you a vendor produced evidence during a window of time. It does not tell you how much risk you are carrying because you rely on them. That gap is the whole reason validated cybersecurity assurance is becoming the standard practitioners actually need. For years we treated a passed attestation as proof that security works. It is proof that a process was followed on the days it was tested. Those are not the same thing, and the distance between them is where most third-party risk programs quietly break.

This article breaks down the difference between compliance-oriented attestation and validated cybersecurity assurance, why the distinction is a measurement problem and not a paperwork problem, and how to evaluate vendor assurance like an engineer instead of a collector of PDFs.

Key Takeaways

• A completed audit confirms a process ran. It does not measure the residual risk you inherit from the vendor.
• Static, point-in-time attestation shifts the validation burden onto you, the relying party.
• Self-defined scope makes two identical-looking reports impossible to compare.
• Validated cybersecurity assurance adds centralized quality oversight so the standard holds across vendors, not just within one report.
• The next era of third-party assurance is measurable, consistent, and defensible.

Compliance and Cybersecurity Assurance Are Not the Same Outcome

Compliance answers a narrow question: did the organization meet a defined set of criteria during a defined period? Cybersecurity assurance answers a harder one: can you trust that the security holds, and can you measure what remains at risk if it does not?

Most attestation frameworks were built to answer the first question well. System and Organization Controls 2 (SOC 2), governed by the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria, is a good example. A SOC 2 Type 2 report evaluates whether controls operated effectively over an observation period, often three to twelve months. That is useful information. It is also interpretive, point-in-time, and scoped by the company being examined.

None of that is a knock on the people doing the work. It is a structural reality. A framework designed to confirm that controls were described and operated is not the same as a framework designed to produce a comparable measure of residual cyber risk across your entire vendor population.

What a Static Attestation Can and Cannot Tell You

When a report lands on your desk, the work does not end. It moves to you. Before you can act on it, you must read the scope, map the controls to the risks you actually care about, interpret any exceptions, and decide whether what you are looking at clears your risk appetite.

That is the interpretive burden, and it is the hidden cost of compliance-oriented assurance. Ten relying parties will interpret the same report ten different ways, which means the same vendor looks different across ten programs.

Scope Is Negotiable, and Scope Decides Everything

The part most relying parties miss is that the company being examined helps define what gets examined. Scope is a decision, and that decision sets the ceiling on what the report can ever tell you.

Two vendors can hand you reports with the same logo on the cover and still have:

• Different systems in scope

• Different controls selected

• Different exceptions disclosed

• Different rigor behind the same designation

When scope drifts, comparability dies. You cannot benchmark posture across vendors who each defined their own test.

Point-in-Time Cannot Govern Real-Time Risk

Your vendor's security posture can change the morning after their observation period closes. Cloud infrastructure changes daily. Software supply chains shift constantly. Artificial intelligence (AI) systems make autonomous decisions that did not exist when the controls were tested. A report that describes one window cannot keep pace with risk that moves every day.

This Is a Measurement Problem, Not a Paperwork Problem

The workflow closes, the report goes in the folder, and the risk stays unmeasured.

A completed review tells you a questionnaire came back, a certificate is on file, and a box is checked. It does not tell you the residual exposure left after controls, contracts, remediation, and insurance are all accounted for. Process completion is not a measurement.

The missing piece is a trusted way to convert fragmented evidence into a comparable measure of the risk that remains. Questionnaires, certifications, audit reports, contracts, and external signals all help, but they differ in scope, rigor, timing, and assumptions. Without a stable unit of measure, threshold decisions drift toward reviewer experience, business urgency, and whatever documentation happened to be available.

That drift becomes a governance problem the moment individual decisions accumulate. One exception is manageable when the exposure is understood. Many similar exceptions across vendors, data types, and geographies create concentration risk that no single report was ever built to surface.

What Validated Cybersecurity Assurance Changes

Validated cybersecurity assurance is built to carry the weight that compliance-oriented attestation leaves with you. Three differences matter most to practitioners.

Centralized quality oversight. Instead of every relying party reinterpreting evidence on their own, a validated approach applies a consistent standard across vendors. The same vendor profile is read the same way, which is the only path to real benchmarking.

Measurable outcomes over described controls. Compliance-oriented assurance is good at confirming a control exists. What you actually need to know is whether the control reduces the risk it maps to, how much residual exposure is left, and how confident the evidence behind it is. That shift from interpretive to measurable is the entire point.

Defensibility. When the board or a regulator asks whether a vendor is safe, “they passed their audit” is not an answer. A defensible position shows what was tested and by whom, the residual risk you accepted and why, the consistent standard you applied, and the measure behind your decision. Validated assurance is built for that moment.

This is not a claim that one framework replaces another or that compliance-oriented attestation has no value. It is a maturity argument. Compliance-oriented assurance got the market started. Modern cyber risk now demands more, and most teams will run both for a long time. The assessors and firms doing this work are part of that evolution.

How to Evaluate Vendor Assurance Like an Engineer

You do not need to overhaul your program overnight to start closing the gap. You need to read assurance the way an engineer reads a system: looking for what it proves, not what it appears to promise.

Start with these questions on your next vendor review:

• What was in scope, and just as important, what was deliberately left out?
• Do the tested controls map to the risks that matter for how you use this vendor?
• What exceptions were disclosed, and what residual exposure do they leave?
• How recent is the evidence, and how much could have changed since the observation period closed?
• Can you state this vendor's residual risk in a way you could compare to your next vendor?

If you cannot answer that last question, you do not yet have assurance. You have documentation. The goal is to move every critical vendor toward a measured, comparable, defensible answer.

For a deeper look at why the industry needs a common measure, join AJ Yawn and HITRUST’s Ryan Patrick on August 26 for The Assurance Gap: What 103 SOC 2 Reports Actually Showed Us, the first session in our new webinar series exploring how to make better, more defensible assurance decisions.

Next Steps

Compliance proves you did the work. Assurance proves the security holds, and measurement proves how much risk is left when it does not. The teams that get to measurable, consistent, defensible assurance first will set the standard everyone else has to meet. The shift starts with one honest question on your next vendor review: not “did they pass,” but “what is my actual residual risk?”

AJ Yawn is a GRC engineer at Rippling and founder of the GRC Engineering Club, writing as an independent practitioner voice. This piece is produced in partnership with HITRUST as part of the FY26 Validated Assurance series.