Connector Hell

A blog post by the vostride Team argues that the proliferation of AI agents across SaaS tools has created "connector hell," in which N products each demanding M connections produce N×M standing credential grants, each a copy of a customer's keys held in another vendor's vault. The post cites a string of real breaches — including Railway, where attackers decrypted some users' encrypted environment variables; OpenCode, where a legacy system was accessed without authorization and OpenAI and Anthropic provider keys were exposed, affecting 1.4% of Console users; Salesloft Drift, where stolen OAuth tokens exposed more than 700 organizations; and Gainsight, where tokens dating back to 2017 let attackers steal data from more than 200 companies — to show that breaking into one trusted integration yields everything its customers already approved.

Connector Hell Every software tool I use has just shipped an AI agent this year. And every agent wants to connect to everything. vostride Team Open the settings page of any tool you use. There's a new tab this year, usually with a sparkly icon . My o11y tool has an agent. So do my CRM, my company wiki, my ticketing system and, since last month, my payroll too. Some of them are really good and add value to our workflows, but they all have the same limitation: an agent is only as good as the context it can see, and your context lives everywhere else distributed . If you sign up for any SaaS these days, the first thing it asks is: Can I connect to your GitHub? And Slack, email, AWS, your calendar, your prod DB, and god knows it might ask for your bank account too. If we do the math, N products each wanting M connections is N×M standing credential grants. Each one is a copy of your keys in someone else's vault, waiting for someone else's breach. We call it connector hell. A breach isn't just leaked credentials anymore. With your AI API key, an attacker can run up your bill distillation attacks . And after all that access, each agent still sees only its own slice. And you end up with confidently wrong root causes, and fixes that stop where the vendor's product ends. And we all know how good agents are at convincing themselves. Let's watch one “fictional” incident. So four Allow Access clicks for one incident RCA… Each time, production was on fire and Allow Access was the fastest way out. Frankly, nobody reads the full permission request list; we all blindly click Allow . And mostly we end up doing Allow and trust or something similar, which grants permanent access. The next day PepaPog is fictional. The failure mode isn't. Railway An attacker accessed Railway users' encrypted environment variables, and decrypted some of them. That's where apps keep the keys to everything else: OpenAI accounts, email, production databases. Railway asked every user on the platform to rotate their keys, even though it thinks only some were hit. OpenCode OpenCode said a breach tied to a large-scale distillation attack affected 1.4% of Console users. A legacy system being decommissioned was accessed without authorization, and the OpenAI and Anthropic provider keys saved there were exposed. Affected users were told to revoke and replace those keys, update their apps and check for unexpected usage. Vercel Vercel says it started with Context.ai, an AI tool one employee used. From there the attacker got into Vercel and read some customers' non-sensitive environment variables. BigCommerce BigCommerce said two third-party apps, Ribon and Ribon 1.5, had their API keys stolen and used to plant malicious scripts in some stores. Its own systems weren't breached. They didn't need to be. Salesloft Drift Attackers stole OAuth tokens from the Drift chatbot and used them to pull data from companies' Salesforce. Google said more than 700 organizations were exposed. Gainsight Attackers used tokens from Gainsight's Salesforce apps to pull customer data. Google confirmed they stole data from more than 200 companies. The oldest token dated back to 2017. Commvault CISA said attackers got into customers' Microsoft 365 through the secrets Commvault kept for their backups. Commvault said a handful of customers were affected and no backed-up data was accessed. Anodot Anodot, a monitoring tool, was plugged into its customers' Snowflake. Through it, hackers stole data from at least a dozen companies. Snowflake said its own systems weren't compromised. Klue An old GitHub token from a 2022 vendor pilot still worked. Attackers used it to take Klue's OAuth tokens, and roughly two dozen customers have confirmed their Salesforce was hit. Same trick every time: break into one trusted integration, and you get everything its customers already approved. this list will be out of date by the time you read it. the math was never going to work PepaPog wasn't evil. It got breached. The problem is the shape: when every product has an agent and every agent wants every tool, your keys end up in N×M places, and your security is only as good as your worst vendor's . And we all know the pressure to reach $1M ARR before Demo Day xD. But teams that run agents seriously are going the other way. They don't want vendors to hold keys to everything. Instead, they are building their own processes and agents software factory is the fancy name for this to store credentials and streamline their agents' access to them. That turns the N×M into N+M. One agent you control connects to N products and M tools, and no vendor gets a copy of everything. Vendors keep their data. You keep the agent, the policy and the audit trail. how does this end? honestly, no idea Nobody knows yet, including the LinkedIn influencers : But we see four ways out. The enterprise gateway. Every company picks one approved agent behind a gateway of reviewed tools. Credentials live in one vault, behind custom policies. This is where agents you run yourself, like Codex https://openai.com/codex/ , Claude Code https://claude.com/product/claude-code , Pi https://pi.dev/ , etc., could win. Vendor agents don't disappear; instead, they become the tools your agent calls. The handoff mesh. Specialists do know more at least the trust-me-bro benchmarks say that . An observability vendor's SRE agent knows its own telemetry better than your agent ever will. So let it investigate, then hand off to the QA or deploy agent with credentials that expire when the task does. Expertise moves around, just like how humans work in real life. The end-to-end ownership. One agent does everything and keeps all the margin. Every vendor is racing toward this. It's also the “instinct” that got us into connector hell, just bigger. Something else. Maybe capability-scoped tokens fix this agent-native authorisation . Maybe agents ask for every access per task. Maybe the solution hasn't been built yet. But what we are sure of is what doesn't survive: N×M standing grants, pre-checked scopes and a “No” button that really means “ask me again tomorrow”. What replaces them is still open: one agent, a team of specialists or something nobody has named yet. we're building for the N+M world Agents write code at lightning speed now. Knowing that it actually works hasn't kept up. At vostride, that's what we work on: verification for the agentic world. So we built agent-qa , a QA agent for your software factory. Your coding agent calls it. It tests your real web and mobile app the way a person would and brings back the evidence. And it connects to exactly one thing: your app.