Your Business Runs on a Chain of Dependencies You Probably Can’t See

Every enterprise is built upon a chain of dependencies it probably can’t describe. Your ERP relies on a cloud provider, which relies on networking hardware, open-source libraries, and third-party identity services, each with their own suppliers. A single business process may pass through dozens of organizations before it reaches your users. 

This is no longer an abstract risk. The Verizon 2025 DBIR found that 30% of confirmed breaches involved a third party, double the prior year. The 2024 Change Healthcare attack illustrated the consequences: a single ransomware incident at one claims processor disrupted prescriptions, froze payments, and cascaded across the entire US healthcare system, affecting 190 million people. The failure was several layers down the chain, in a system most of those affected had never heard of. These are not edge cases: they are the predictable consequence of shared infrastructure. 

This does not mean we have to audit every layer. The shared responsibility model exists for good reason – we trust our hyperscalers to manage their servers and secure their hypervisors – but the model demands that you know where your responsibility begins, what sits between your business and the infrastructure beneath it, and what happens when a dependency within your scope fails. 

SaaS Has Moved From Convenience to Critical Infrastructure 

A decade ago, SaaS handled peripheral functions. Today, payroll, customer identity, and financial reporting run on platforms entirely outside the enterprise’s direct control. For organizations running critical systems on PaaS, the dependency chain includes the managed service provider, the hyperscaler, the identity provider, and the backup vendor. That complexity is not inherently a problem if someone in the chain owns visibility across it: the question is whether anyone does. 

Procurement has not kept pace. Most SaaS assessments still ask about encryption at rest while missing the harder questions: what subprocessors does this vendor use, and who notifies you when one is breached? The shared responsibility model assumes clear boundaries, but SaaS has blurred them beyond recognition. When something goes wrong, the organization holding the regulatory obligation often has no direct relationship with the party where the failure occurred. The responsibility was always yours; the visibility was not. 

AI Platforms Are Breaking Trust Boundaries by Design 

AI accelerates the dependency problem because these agents often require broad access. A traditional SaaS tool reads a defined dataset. An AI assistant often requests cross-domain access (email, documents, calendars, chat, code) to be useful, creating an inherent tension with the principle of least privilege.  Last year researchers demonstrated that enterprise copilots could be manipulated through prompt injection to violate their own trust boundaries, exfiltrate data, and enable lateral movement between agents, all without triggering a single alert. The OWASP Top 10 for Agentic Applications (2026) addresses exactly this class of risk. 

Agentic assistants operate inside the trust perimeter with the user’s identity and implicitly inherit that user’s access. Traditional security tooling (EDR, DLP, WAFs) was not built to observe AI retrieval pipelines. When an assistant accesses a restricted document, no file is downloaded and no perimeter is crossed. The security stack sees nothing. For organizations deploying AI, the main security questions are what the platform can access, whether your controls can detect when something goes wrong inside it, and whether your incident response playbooks account for trust boundary violations that your existing tooling will not see. 

You Cannot Secure What You Cannot Describe 

Managing supply chain risk starts with knowing what your supply chain contains. Software Bills of Materials (SBOMs) provide a machine-readable inventory of every component and dependency in a piece of software. When Log4j was disclosed in 2021, organizations with SBOMs determined their exposure within hours. Those without spent weeks. You cannot patch what you do not know you are running. 

Regulators are codifying this. The EU Cyber Resilience Act mandates machine-readable SBOMs, NIS2 requires supply chain security measures for essential entities, and CISA’s 2025 guidance, co-authored with the NSA and 19 international partners, pushes toward verified hashes, license data, and generation context.  SBOMs are not a panacea: they do not cover the full dependency chain of cloud providers, SaaS subprocessors, and AI access patterns, and the same principle of transparency must extend beyond code into service delivery – but SBOMs are the foundation. 

What Comes Next 

The industry spent the last decade optimizing for speed of adoption. The cost is now visible in every major supply chain breach. The organizations that responded in hours rather than weeks were not the ones that tried to own every layer. They knew where their responsibility began, what sat within it, and who to call when something beneath it broke. They required transparency from suppliers and managed service providers, and treated dependency mapping as a security discipline rather than a procurement exercise. Give each AI agent its own identity and scope its access like any other privileged account, because an agent that inherits a user’s full permissions is not just a productivity tool – it’s an unmanaged attack surface. The question for every enterprise in 2026 is whether you can describe the dependencies on your side of the shared responsibility model, and whether you are prepared for what happens when one of them fails. 

About the author: Dave Manning is the Chief Information Security Officer at Lemongrass.