A lot of companies will get breached this year. Not because AI agents got dangerous, but because teams built their own connectors and gave an agent the keys. Build vs buy used to be a cost decision, a spreadsheet argument about engineering hours against subscription fees. In the agent era it is a custody decision: every integration you build in-house is a live credential you now own, forever, across every ad account and customer record it touches. And the layer worth buying instead has quietly grown past plumbing. It now carries three jobs at once: holding the keys, giving agents a governed way in over MCP, and keeping analytics consistent on one knowledge graph across every platform you connect.
This expands on a post I published on LinkedIn about custody.
Key Takeaways
- The classic build vs buy analysis compares cost, speed, and maintenance. All of that still applies, and it now misses the largest line item: who owns a standing credential for years after it was created.
- Almost nobody rotates the keys they build. GitGuardian retested credentials that had leaked to public GitHub and were confirmed valid in 2022: in January 2026 more than 64 percent were still valid. Four years, still open.
- Wire one of those keys into an agent that runs while you sleep and you have the real risk of the agent era: not the model, a standing key nobody revokes, with a heartbeat.
- Buying the boring layer changed meaning. It is no longer just pipelines: it is credential custody in a vault, MCP-based access so agents reach platforms without holding platform keys, and a knowledge graph so the same analytics work across whatever is connected.
- Those last two are the part almost no team can justify building in-house, because they only pay off across hundreds of connectors and every future agent you add.
- Build the part that is actually yours: your metrics logic, your models, your workflows. Custody, connectivity, and the semantic layer are liabilities to own and commodities to buy.
The Question Changed Under the Spreadsheet
The traditional framework is not wrong. We maintain a full build vs buy decision guide that walks through total cost of ownership, time to value, maintenance burden, and scaling, and every factor in it still holds. If anything, the cost side of the argument has only hardened: platform APIs deprecate, schemas drift, and an in-house connector is never finished, only temporarily working.
What changed is that the spreadsheet now misses the largest line item. An integration is not just code that moves data. It is a credential: an API key or OAuth grant with real permissions on a real system, often broad ones, because narrow scopes take longer to figure out and the sprint was ending. Build twenty connectors and you own twenty standing credentials, spread across ad platforms, CRMs, and warehouses, each one created by someone who may no longer be on the team.
Cost is a number you pay once and can see. Custody is a liability you hold continuously and mostly cannot see. That asymmetry is why the old framing keeps producing decisions that look rational and age badly.
The Evidence: Keys Outlive Everyone's Attention
The claim that nobody rotates credentials sounds like an exaggeration until you look at the one dataset that measures it directly. GitGuardian's State of Secrets Sprawl report, published in March 2026, retested credentials that had leaked to public GitHub and were confirmed valid back in 2022. In January 2025, nearly 70 percent still worked. Retested again in January 2026, the validity rate was still above 64 percent.
Read that plainly: keys that were publicly exposed, in the most scanned code-hosting surface on the internet, stayed live for four years. Those are the leaked ones. The credentials your team built into internal connectors, the ones nobody outside the company has ever seen, have even less pressure on them to ever be rotated.
Now add the agent. A credential wired into a nightly script was already a risk, but a slow one. A credential wired into an agent that acts continuously, across systems, without a human watching each call, is the same standing key with a heartbeat. The failure mode is not the model doing something clever and malicious. It is the oldest failure in security, an unrotated key with too many permissions, now attached to something that never sleeps. We have written about the other side of this same coin, what happens on the day those keys get revoked: the security action and the outage arrive as one event. Custody is how you end up on the wrong side of both.
Talk to an Improvado expert about taking standing platform keys out of your stack.
What "Buy the Boring Layer" Means Now
The original argument for buying integration was convenience: someone else maintains the pipes. The agent era added two requirements that change what the boring layer even is, and both are things an in-house build almost never gets to.
First, custody itself. The layer holds the credentials in a vault, rotates them, scopes them, and carries the audit trail. Your team connects a platform once, through OAuth on the vendor's side, and no engineer of yours ever pastes a long-lived key into a config file again. When someone leaves, there is no archaeology project to find what they authorized. When a platform forces a migration, it is the vendor's sprint, not yours.
Second, MCP access for agents. Agents do not just need data delivered on a schedule, they need to reach tools and platforms at the moment of a task. The emerging standard for that is MCP, and the sane architecture is one gateway rather than fifty separate servers: agents authenticate to a single governed endpoint, and the gateway holds the platform connections. The agent never possesses a platform key at all. Access on shared connections is enforced with deterministic role-based control and workspace isolation, every call lands in one audit trail, and cutting an agent off is one action at one place instead of a hunt across twenty platforms. Building that yourself is a second product, and its entire value is that somebody else already built it, hardened it, and answers for it.
Third, a knowledge graph over whatever is connected. Moving data is the easy half. The hard half is that every platform names things differently, defines metrics differently, and holds its own fragment of the customer. A knowledge graph layer resolves that once: campaigns, channels, accounts, and metrics become one set of entities with one set of definitions, regardless of which platform they came from. Connect a new channel and it joins the same graph, so the analytics you already have extend to it instead of starting over. And for agents the graph is the memory layer, not another search index: the place where every agent reads and writes what is true about your business, instead of each one keeping a private copy. That is what makes work seamless across platforms, an agent or a dashboard queries the graph, not twenty schemas, and the answer means the same thing wherever the underlying spend or revenue actually happened.
Put the three together and the build vs buy comparison stops being about pipes entirely. In-house gets you data movement plus a growing pile of keys. The bought layer gets you movement, custody, an agent-ready MCP surface, and a semantic layer that makes every connected channel analyzable the same way. The second list is not a build project, it is a product category.
Build the Part That Is Actually Yours
None of this is an argument against building. It is an argument about what deserves your engineers.
Your metric logic, the way your business defines a qualified lead or true ROAS, is yours. Your models, your bidding strategies, your workflows, the agents you design around your own processes, all yours, and all of it compounds. A connector to a platform API compounds for nobody: it is the same undifferentiated liability in your codebase as in ten thousand others, except you are the one holding its key.
The clean division: build what encodes your judgment, buy what holds credentials and speaks to platforms. You keep the responsibility either way. The question is whether you also keep the keys, and when the breach report reaches your board, "we built it ourselves" is not the sentence you want to be defending.
Four questions that settle a vendor conversation quickly:
Where do credentials live, and who rotates them? The answer should be a vault on their side, with rotation and audit as their job, and your team never handling raw keys.
How do agents connect? The answer should be a single governed MCP endpoint with per-workspace isolation and role-based control, not a key handed to each agent.
What happens to my analytics when I connect a new platform? The answer should be that it joins the existing graph, same entities, same definitions, working from day one, not a new integration project.
What can I shut off, and how fast? One place, within the hour, with the audit trail showing everything the access ever touched.
That is what we build at Improvado: hundreds of platform connectors behind one governed layer, credential custody and access control that belong to the company rather than to whoever set up the connection, an MCP gateway so agents reach every connected platform without holding a single platform key, and a knowledge graph that keeps entities and metric definitions consistent across every channel you plug in. The part that is actually yours stays yours.
Talk to an Improvado expert about agent-ready access and one knowledge graph across your channels.
Frequently Asked Questions
Why is build vs buy a custody decision now?
Because every integration is a credential before it is code. An in-house connector means your company owns a standing API key or OAuth grant with real permissions on a real system, indefinitely, maintained by whoever happens to remember it exists. The classic cost comparison never priced that, because before agents the exposure grew slowly. Once agents act on those credentials continuously and unattended, custody, meaning who holds the key, who rotates it, who can revoke it within the hour, becomes the deciding factor, and it is the one factor an in-house build structurally cannot outsource to itself.
What does the GitGuardian statistic actually measure?
GitGuardian's State of Secrets Sprawl report, published in March 2026, retested credentials that had leaked to public GitHub and were confirmed valid in 2022. Nearly 70 percent still worked in January 2025, and more than 64 percent were still valid in January 2026, four years after leaking. The population is credentials exposed in public repositories, which is the most visible and most scanned surface there is. Keys buried in private, internal connector code face even less pressure to be rotated, which is why the number is best read as an optimistic bound on rotation discipline, not a worst case.
What is MCP and why does it matter for this decision?
MCP, the Model Context Protocol, is the emerging standard for how AI agents reach tools and data sources. It matters for build vs buy because agents change what an integration layer must provide: not just scheduled data movement, but governed live access at the moment of a task. The architecture that keeps custody intact is one MCP gateway holding all platform connections, with agents authenticating to the gateway rather than holding platform keys, role-based control on shared connections, workspace isolation, and one audit trail. Building and hardening that gateway in-house is a second product on top of your connectors, which is precisely the trap the buy side exists to avoid.
Where does a knowledge graph fit into an integration decision?
Data movement solves delivery, not meaning. Every platform names campaigns, audiences, and metrics its own way, so twenty connected platforms are twenty vocabularies until something unifies them. A knowledge graph layer resolves entities and metric definitions once, across everything connected, so a new channel joins the same graph and existing analytics extend to it immediately. For agents the graph doubles as shared memory: one place every agent reads and writes what is true about the business, instead of each agent holding a private copy of strategy. If the layer you buy does not carry this, you have bought pipes and kept the hardest problem.
Is building in-house ever the right call?
Yes, for the things that encode your judgment: metric logic, models, custom workflows, agents built around your own processes. That work compounds and differentiates. The line is whether the thing you are building creates a standing credential to someone else's platform. A connector does, and it differentiates nothing, the same connector exists in thousands of codebases, except each copy carries its own unrotated key. Build above the integration layer, not inside it.
We already built our connectors. What is the realistic path out?
Inventory first: list every in-house integration and the credential behind it, including who authorized it and what it can reach. Then migrate by blast radius, moving the connectors whose keys touch revenue systems and customer records first, revoking each in-house credential as its replacement goes live, so the standing-key count actually falls instead of doubling. The pattern to avoid is running both layers indefinitely, which keeps every liability of building while adding the cost of buying. Most teams find the deprecation list is also the first complete credential inventory they have ever had, which is its own argument for doing it.
