Your AI Summary Shouldn't Require a Copy of Everything

Most enterprise AI integrations quietly centralize your data to work. The Model Context Protocol offers a different deal, and a much smaller blast radius.

Photo: panumas nikhomkhai / Pexels

It usually starts with a reasonable request. Someone in leadership wants an AI that can say how the engineering org is really doing: where work is piling up, where things are slipping, who's stretched too thin. Fair question. Then you cost out what it takes to answer it, and the picture gets uncomfortable.

The first time a vendor walked me through their setup, the catch was sitting right there in the architecture diagram. To produce that one clean summary, they wanted us to pipe our GitHub history, our Jira tickets and a slice of our HR records into their cloud. Not a query here and there. Copies. Our data lifted out of the systems it lived in and pooled in one place so a model could read across all of it at once.

That pooling has a name: data blending. It has quietly become the default way most AI features get built, and the reason is simple. A model gives better answers when it can see more context, so the vendor asks for more context. The incentive only points one way, and "send us everything" is where it lands.

The trouble is what you've built once all of that sits in one bucket.

One bucket becomes one very large target

A vendor holding your source code, your tickets and your people data is now one of the most attractive targets in your whole supply chain. Centralizing didn't reduce your risk. It concentrated it, and handed it to someone whose security you don't control and can't fully see.

It also changes the math on a breach. When everything is blended, a compromise at that vendor isn't the loss of one data source. It's the loss of all of them, already cross-referenced and conveniently in one place. The blast radius is the whole building.

Then there's the quieter cost: scope. Every system you copy into that pool widens what your auditors, your DPO and your compliance team have to account for. Under GDPR you're meant to collect the minimum you need and keep it where you can justify keeping it. Blending pushes hard the other way.

A different arrangement

This is where the Model Context Protocol comes in, and it's worth being precise about what it is before anyone oversells it.

MCP is an open standard, introduced by Anthropic and since adopted across most of the major AI platforms. The usual shorthand is "USB-C for AI": one common way to plug a model into the tools and data it needs, instead of a bespoke integration for every pairing.

The part that matters here is how it's arranged. Rather than copying your systems into one place, MCP leaves each source where it lives and exposes it through its own small server: a GitHub server, a Jira server, a database server. The model's client connects to each independently and asks for what it needs, when it needs it. The data stays put. The only place the sources come together is inside the context window of the model you're already running, and once the task is done, it's gone.

Nothing gets pooled into a permanent shared copy. The model sees a transient, assembled view for the length of one task, and no longer.

Why security teams tend to relax a little

Because each source is queried on its own, a problem at one connector stays at that connector. A breach of your Jira server doesn't hand anyone your code or your HR records; they were never sitting together. You can revoke or rotate one connection without unpicking a giant blended store. And the GDPR conversation gets easier, because you're querying narrowly and keeping data where it belongs.

A caveat, and an important one: MCP is not a security guarantee, and it's a mistake to treat it as one. It brings its own surface to defend. Every server still needs real authentication, sensible scoping and proper logging, and the community is working through those questions in the open. Risk doesn't vanish. What changes is its shape, from one giant honeypot into something you can reason about, contain and explain. That's a much better place to be standing.

Where presence fits

This is the thinking behind SquadBear. Team availability — who's on leave, which office has a public holiday, where focus time is blocked — is genuinely useful context for an AI trying to make sense of how work flows. It's also exactly the kind of data you should never have to ship to a third party to get value from.

So we treat it the way MCP treats everything else. Availability lives in its own server, queried directly, never blended into someone else's database. Your corporate AI can read the team's rhythm without anyone exporting a personnel file.

The old deal asked you to trade your data's safety for a useful answer. It was never as necessary as it looked, and there's a cleaner way to get the answer and keep the data where it belongs.

See the cleaner arrangement

Spin up the SquadBear demo, point your own AI client at its MCP endpoint, and watch it answer an availability question without a single record leaving the server. When your security team is satisfied, get started free.

More from the series: the velocity blindspot shows what this unlocks for planning, and burnout tracking without the big brother covers the privacy line we won't cross.