Your AI Summary Shouldn't Require a Copy of Everything

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, 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 AI features get built, for a simple reason: a model gives better answers with more context, so the vendor asks for more of it. 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 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 costs you every source at once, already cross-referenced and 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 compliance people have to account for. GDPR expects you to collect the minimum and keep it where you can justify it. Blending pushes hard the other way.

A different arrangement

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

MCP is an open standard, introduced by Anthropic and now adopted across most 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 the arrangement. Instead of copying your systems into one place, MCP leaves each source where it lives and exposes it through its own small server (one for GitHub, one for Jira, and so on). 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 meet is inside the context window of the model you're already running, and once the task is done, that view is gone. Nothing is pooled into a permanent copy.

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 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.

One caveat, and it matters: MCP is not a security guarantee. It brings its own surface to defend, and every server still needs real authentication and sensible scoping. Risk doesn't vanish. It changes shape, from one giant honeypot into something you can contain and explain to an auditor. That's a much better place to stand.

Where presence fits

This is the thinking behind SquadBear. Team availability (who's on leave, which office has a public holiday) 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.

So we treat it the way MCP treats everything else. Your workspace has its own MCP endpoint, and a connected agent acts as you, with your role's permissions and nothing more. Everything it does lands in the same audit trail as the web app. A manager's agent can see their reports' availability; an employee's agent sees only their own. You pick the scopes when you connect (read-only leave data is a fine place to start), and they stay fixed until you reconnect.

Once it's wired up, the privacy point stops being abstract. Try this with your own AI client:

Check that you're connected to my SquadBear workspace by calling whoami, then tell me who on my team is out next week.

You get the answer, and nobody exported a personnel file to produce it.

The old deal asked you to trade your data's safety for a useful summary. There's a cleaner way to get the summary and keep the data where it belongs.

See it for yourself

Spin up the SquadBear demo, point your AI client at its MCP endpoint, and watch it answer that question live. When your security team is satisfied, get started free.

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