"Claude can now connect to your systems" — but how, exactly?
You've probably heard some version of this claim: Claude can connect to Outlook, to your line-of-business system, to a database, to almost anything. We've written about this ourselves — Claude in the Browser Is Not an AI Strategy was about exactly this: getting Claude into the tools you already use.
What we didn't go deep on then is how that connection actually works, and why it's safe. The answer is called MCP — Model Context Protocol. It's not just a technical footnote. It's the actual reason Claude can do more than answer questions in a chat window, and it's the thing that decides whether you should trust the connection or not.
What MCP actually is
Think of MCP as a standardised connector between Claude and a system you use — a bit like a USB port, except for data and actions instead of power. Before MCP, every connection to every system had to be custom-built from scratch, every time. With MCP, there's one standard way to build the connection, and it works the same way regardless of which system it's talking to.
Concretely, that means: once a connection to, say, your line-of-business system or email platform is built, Claude can use it in a structured, predictable way — not just reading information, but in some cases carrying out actions too, always with a human approving anything that matters.
This is exactly what sits behind both Claude Live and Claude Cowork: the connections to Outlook, SharePoint, and line-of-business systems we've built for clients are MCP connections. When we've previously written that "if there's no connection to a tool you use, we build it ourselves," this is the technical mechanism behind that promise.
The trust question: who actually has access to what?
Here's the question that should actually concern you, and the one MCP recently got a concrete answer to: if Claude can connect to a system, who decides what Claude gets to see, and as which user?
Until recently, the honest answer was often "it depends how the connection was set up" — not a particularly reassuring sentence. The latest version of the MCP standard fixes this with a requirement for proper login (technically, OAuth) for any connection handling sensitive or account-based information. In practice, that means two things for a Norwegian SMB:
For connections to external vendors: If Claude connects to a vendor's system — an accounting platform, a payment provider — you log in with your own account with that vendor, the same way you would in a browser. Claude only gets access to what your account actually has access to. No shared password, no hidden access beyond that.
For internal systems: If Claude connects to something internal — a line-of-business system, a database, an internal knowledge base — the connection can sit behind the same login system you already use for everything else (Microsoft Entra ID is the common one for Norwegian M365 businesses). That means an employee logs in as normal in the morning, and Claude inherits exactly the same access that employee already has — no more, no less. No separate user administration to maintain on the side.
That second point is exactly the same principle as RBAC — role-based access control — which we build into every delivery. MCP with proper authentication is RBAC thinking, applied specifically to AI connections.
What this means practically for you
You don't need to understand the protocol in detail to benefit from it. What you need to know is this:
- Connections between Claude and your systems are no longer a one-off project built from scratch. The standard means connections can be reused and updated without starting over each time.
- Access can and should follow the employee's existing login — not a separate, standalone access grant just for the AI tool.
- Ask your vendor "do you use MCP, and how is authentication set up?" before connecting anything to sensitive data. The answer tells you a lot about how well thought-through the connection actually is.
For businesses with an in-house IT department who want to go beyond one-off integrations — preparing your Microsoft 365 environment for multiple AI agents, building your own agent blueprints internally, automating workflows across systems — this is exactly what our Enterprise Solutions offering is built for.
The point that keeps repeating
You don't need to manage MCP yourself, and you won't think about it day to day. But it's worth knowing it exists, because it's the difference between an AI connection that's safe and traceable, and one that's a black box nobody actually understands.
AI starts not with technology. It starts with structure.
Get in touch for a free AI Ready assessment →
Read also: Claude in the Browser Is Not an AI Strategy · Claude Cowork: When the AI Agent Moves to Your Desktop — And What Norwegian SMBs Must Structure First