There is a concept in security called the attack surface: the total number of points where an unauthorized agent can attempt to enter, extract data, or cause damage. For most organizations, the attack surface has been growing for years without anyone explicitly deciding to grow it. The mechanism is the SaaS integration stack.
The average enterprise now runs more than 130 SaaS applications, according to Okta's 2025 Businesses at Work report. Each of those applications connects to others through APIs. Each connection is, by definition, a trust boundary: a point where one system hands off data or authority to another, where the receiving system must decide how much to trust what it was sent and who sent it. Most of those trust boundaries were designed with human actors in mind. Almost none were designed to be interrogated by an AI agent operating at machine speed, at scale, continuously.
The attack surface does not grow linearly with the number of vendors. It grows with the number of connections between vendors. Ten vendors with three integrations each is not ten attack surfaces. It is a web of potential traversal paths, each one a different authentication model, a different permission scope, a different incident response team.
What a trust boundary actually is
When your property management platform sends a tenant's data to a screening vendor, it is making a trust decision: it is asserting that the data it sends is legitimate, and it is trusting that the screening vendor will handle it correctly and return a reliable result. The screening vendor, in turn, connects to credit bureaus, identity verification services, and fraud detection APIs. Each of those connections is another trust decision. The chain compounds.
In a human-operated world, this is manageable because humans are slow. A fraudster trying to manipulate the outcome of a tenant screen has to work through each step sequentially, and the friction at each step is a natural deterrent. An AI agent operates differently. It can probe every endpoint in the chain simultaneously, test each trust boundary independently, and identify the weakest link in the entire stack within minutes. The friction that made the chain manageable has been removed.
What makes this particularly difficult is that the weakest link is rarely at the primary vendor. It is almost always at the secondary or tertiary integration. The primary vendor, facing direct customer scrutiny, has usually invested in security. The smaller vendor they connect to, less visible and less scrutinized, often has not. The AI agent does not care which vendor it enters through. It just needs one open door in the chain.
Average number of SaaS applications running in an enterprise organization, per Okta 2025.
Minimum new API surfaces created per integration. Two-way connections create at least two new potential entry points.
Of breaches in 2025 originated through a third-party vendor or supplier, per Verizon DBIR 2025.
The rental economy has a particularly large surface area
Property management is not a single-system problem. A mid-sized operator running 500 units typically connects their core platform to a screening vendor, a payment processor, an insurance provider, a maintenance coordination tool, a resident communications platform, a document signing service, and a credit reporting integration. Each of those vendors has their own sub-integrations. The aggregate surface area is large and, in most cases, has never been audited as a connected whole.
This matters because the data flowing through those integrations is not benign. Social insurance numbers, banking credentials, income verification documents, tenancy histories, payment behavior: all of it moves through API calls between systems that were built independently, by different teams, to different security standards, in different eras. The assumption that the data is safe because the primary platform is secure is precisely wrong. The primary platform is often the most secure point in the chain.
Insurance is the most exposed layer
Carriers operating in the rental market are downstream of all of these integrations. When a carrier's underwriting AI prices a policy, it is drawing on data that has passed through multiple trust boundaries before it arrives. If any point in that chain has been manipulated, the carrier is not pricing real risk. It is pricing fabricated data with real capital.
Traditional insurance conversion in this market sits at 2 to 5 percent. Some of that gap reflects product-market fit. A significant portion reflects carriers' rational reluctance to write policies in a data environment they cannot verify. The integration stack is not just a security problem. It is the reason underwriting remains expensive and coverage remains scarce.
Of data breaches in 2025 entered through a third-party vendor, not the primary target organization. The weakest link in the chain is rarely the most visible one.
Consolidation is the architectural answer, not a preference
The instinct in most organizations is to respond to integration security problems by adding another layer: a security vendor, an API gateway, a monitoring tool. This is understandable. It is also a version of the original problem. You are adding another integration, another trust boundary, another vendor whose own sub-integrations have not been audited.
The architectural answer is to reduce the number of trust boundaries, not to monitor them more closely. A single regulated entity handling payments, insurance, credit, identity, banking, and lease compliance under one consent model and one compliance posture does not have an integration chain to exploit. The data does not travel between vendors. It lives in one system, under one set of controls, subject to one regulatory framework.
This is not primarily a convenience argument, though it is also that. It is a security argument. The vendor-of-vendors model that most of the rental economy runs on today is not just inefficient. It is structurally vulnerable in a way that becomes more visible with every improvement in AI agent capability. The consolidation case was already strong on efficiency grounds. On security grounds, it is becoming urgent.
Every integration you remove is a trust boundary you eliminate. Every trust boundary you eliminate is a traversal path an agent cannot use. The most secure architecture is also, increasingly, the most operationally efficient one. These used to be separate arguments. They are now the same argument.
The organizations thinking about this clearly are not adding vendors to address the vendor problem. They are asking a different question: what would it take to operate the entire financial layer of this business through a single regulated entity, and what would that actually change? The answer, for those who have worked through it, is that it would change almost everything that matters.