Over the next decade, the way we define security failures is going to change. No longer will it begin with an unpatched server or a careless employee clicking the wrong link. The root cause will be something far more ordinary, yet harder to see: third-party services.
Right now, organizations are allowing outside services to sit inside their workflows, applications, and data, then, once in place, assuming that they will apply the same levels of protection as the organization itself would. This assumption is what we call delegated trust, and it is quietly becoming the largest attack surface in modern security.
Delegated trust exists whenever a company relies on third parties, including SaaS platforms, embedded JavaScript, analytics tools, identity providers, AI services, customer support widgets, payment processors, and data enrichment APIs. The moment one of these is integrated into a business’s core system, security teams are no longer defending only the company’s perimeter. They are defending the combined security posture of entities they do not control—other vendors, sub-processors, cloud providers, integrations, and downstream dependencies.
Security leaders have understood this risk in theory for years. A decade ago, third-party risk was largely a procurement concern that focused on protecting data at rest. What has changed is the scale, speed, and level of privilege that is now being delegated. Today, third-party risk lives inside runtime environments, production identity flows, and customer-facing experiences.
Now, organizations spend exorbitant sums hardening their development pipelines, but they still suffer major incidents because a “trusted” external tool was compromised, misconfigured, silently updated, or simply evolved beyond what was originally approved.
The bottom line is this—while the perimeter has moved, most security programs have not.
How Delegated Trust Became the Default
Two shifts help explain why delegated trust has exploded. The first is SaaS adoption, which has shifted from a top-down procurement process to a self-service model. Today, teams are signing up for tools in minutes, connecting them to corporate data, and moving sensitive information long before any security reviews occur. This puts security teams in catch-up mode, trying to piece together what was purchased, who is using it, what data was sent, and what permissions were granted.
The next shift is the evolution of modern software. Software today is not built. It’s assembled using externally developed code and APIs, and once deployed, it’s commonplace for embedded scripts and agents to operate with deep privileges. For example, some are allowed to collect behavioral telemetry or interaction data to see what users click, what they type, which errors occur, and which paths they take. In many cases, they have enough context to infer intent.
This is why analytics and monitoring tools have become such a lightning rod. Yes, they may be framed as “just harmless measurement tools,” but they are pervasive and powerful. If an analytics vendor is compromised, even partially, the downstream blast radius is not theoretical.
Why Point-in-Time Controls Are Failing
Most organizations still manage delegated trust using frameworks designed for a slower world. Examples include security questionnaires, annual reviews, SOC 2 reports, vendor scorecards, and contract clauses. These are point-in-time controls applied to systems that change continuously.
In today’s world, vendors ship features weekly. They add sub-processors, expand integrations, modify telemetry, adjust permissions, and re-architect infrastructure. The bottom line is that the “approved” version of a tool is rarely the one companies are running months later.
There is good news: security teams understand this. But of course, there is also bad news. Traditional assurance methods were never designed to be continuous, and most organizations lack the resources to treat every vendor as a constantly monitored internal system. For these companies, “continuous monitoring” often means repeating the same static process once a year.
AI Turns Delegated Trust Into a Live Wire
AI does not merely add risk. It accelerates delegated trust into something dynamic and unpredictable.
AI services ingest highly sensitive data, invoke additional APIs, chain sub-processors, and evolve rapidly as models and integrations change. Next thing you know, data begins traversing paths that are difficult to map and even harder to govern. The technology stack becomes a living system that shifts faster than traditional controls can track.
On the plus side, AI gives defenders new capabilities. It can monitor behavior at scale, detect changes in code execution, data flows, permissions, and integrations, and flag drift that would otherwise go unnoticed in periodic reviews.
But this visibility creates new challenges. When businesses receive alerts indicating that a critical vendor has changed behavior, they don’t have the luxury of simply shutting it down. They also cannot instantly re-architect dependencies or unwind operational reliance overnight. Detection without leverage becomes frustrating.
This is why delegated trust is not primarily a tooling problem. It is an incentive problem.
Why Procurement Is Becoming a Security Control Point
Today, procurement can control which tools enter the business. It shapes contracts, data-sharing terms, sub-processor disclosures, breach notification requirements, and exit rights. It also identifies which vendors matter most based on spend, renewal cycles, and integration depth.
Yet, procurement teams are traditionally measured on cost savings and speed, not risk reduction. Delegated trust turns vendor security into a financial outcome, but saving $10,000 on a contract matters little if the relationship exposes the organization to a $10 million incident.
That model is no longer sustainable. Boards must begin treating procurement as part of the enterprise risk engine, not merely as a cost optimizer. Empowering procurement to enforce security constraints early reduces shadow IT and prevents the familiar cycle of selecting tools first and asking security later.
Trust Must Be Measured, Not Assumed
Delegated trust will define the next decade because it sits at the intersection of modern business reality and modern threat reality. Organizations are building faster by outsourcing more. Adversaries are scaling faster by exploiting what organizations cannot see.
The most resilient companies will not be the ones with the longest questionnaires. They will be the ones who stop treating trust as a static attribute and start treating it as a measurable, monitored, and constrained relationship.
That shift is no longer optional.
Clarence is the cofounder and CEO at Coverbase, the leading AI procurement and risk company that recently raised $20m from top investors to automate 90% of vendor management. Prior to this, he cofounded Unit21, Google-backed company that raised $92m to help top financial institutions combat fraud and money laundering with AI. He has degrees in Computer Science and AI from Stanford, published the book "Machine Learning and Security" with O'Reilly Media, and teaches AI and security at UC Berkeley.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.