How AI connects to company systems, and what MCP is

AI reaches a company system only through a connection somebody sets up, and it can see and do only what the account behind that connection allows. MCP, the Model Context Protocol, is the common standard for building those connections, so a connection built once works with any assistant that supports it.

An assistant with no connections can work only with what somebody types into it. Connected, it can pull the order history for the customer on the phone, and update the record afterwards. Neither of those is the model getting cleverer. Somebody wired it to a system and decided what it may do there.

So “can the AI see our CRM” has an ordinary answer: only if somebody connected it. The question that decides more is the second one: whether it can only read what is there, or whether it can change it.

What a connection actually is

Tools set out the shape. The model writes out a request naming what it wants, something else runs that request, and the result comes back into the conversation. A connection to a company system is the same shape, pointed at the systems the business already runs on.

The model never touches the CRM. It writes a line of text naming a lookup and a customer. A piece of software sitting between the model and the CRM reads that line, checks it against the small list of lookups it offers, calls the CRM the way any other software would, and hands back what comes out as text. The model then reads that text the way it reads anything else in front of it. There is nothing unusual in the mechanism. The model’s only contribution is still writing.

Example

Let’s say a sales rep asks an assistant what Acme bought last year. The model writes a request naming one lookup, account history, with one input, Acme. The connector runs that lookup against the CRM under a login somebody set up for it, gets 6 rows back, and puts them into the conversation. The model reads the 6 rows and writes the answer. It did not search the CRM, and it could not have asked the CRM anything the connector does not offer.

Two things follow, and both do more work than they look like they do.

A connection is a fixed list of operations, written when the connection was built. A system that publishes such a list for other software to call has an API, and “does it have an API?” is the question of whether anything can be wired to it at all. An assistant connected to the CRM has whatever that list contains, and nothing else in the CRM exists as far as it is concerned.

And every one of those operations runs as somebody. The system on the other side sees a login, checks its permissions the way it would for a person, and refuses what that login is not allowed to do. Whoever set the connection up chose that login, and that choice is the real limit on what the assistant can do.

Reading and acting are two different things

Every connection falls on one side of a line, and which side it falls on matters more than which system sits on the other end.

A read returns information. When it goes wrong, the cost is a wrong answer, or information reaching somebody who should not have it. The second of those is serious and is a question about where data travels. A wrong answer is discarded. A leak cannot be, which is why it is the one read that behaves like an action.

An action changes something that was true. A record is updated, an email reaches a customer, money moves, a row is gone. When it goes wrong there is a person who received something, or a field whose previous value nobody wrote down.

Example

Let’s say the same CRM is connected twice, once to read opportunities and once to update them. On a bad day the read gives a stale answer about the Acme renewal and somebody corrects it in the meeting. On a bad day the write sets the wrong close date on 12 opportunities, the forecast is wrong from that morning, and the original dates are not recorded anywhere except in whatever the CRM keeps of its own history.

The common standard for these connections splits them along the same line: things a system offers for reading, and things it offers for doing. The published guidance on the doing half is that a person should be able to refuse a call before it runs, that sensitive operations should ask for confirmation, and that every call should be logged. That is the same approve, sample or check-with-software question as anywhere else in AI, arriving at the moment somebody configures a connection.

One standard way to connect

For years, connecting an assistant to a system meant building that connection for that assistant. The work did not carry. A CRM connector written for one product did nothing for the next one, and a company running 3 assistants across 6 systems was looking at a great deal of very similar code. That is why so many “AI for our company” efforts turned out to be integration projects with a model at the end.

There is now one agreed way to do it. A system publishes what it offers in a standard format, an assistant asks in the same standard format, and anything that speaks the format can talk to anything else that speaks it. The standard is the Model Context Protocol, MCP for short. The piece of software that offers one system’s lookups and actions in that format is called an MCP server.

It came out of Anthropic, which then gave it away. In December 2025 it went to the Agentic AI Foundation, a fund inside the Linux Foundation, co-founded with Block and OpenAI and supported by Google, Microsoft, AWS, Cloudflare and Bloomberg. The point of that move is that no single company decides what the standard does next, which is the same arrangement that sits under a lot of the software businesses already depend on. On the other side, it is now spoken by the major assistants and coding tools, Claude, ChatGPT, Gemini, Microsoft Copilot, Visual Studio Code and Cursor among them. A standard only one vendor speaks is not a standard, and this one is past that.

What it changes for a business is the arithmetic. The connection to the order system is written once and works with whichever assistant the company picks next, so the choice of assistant stops deciding which systems it can reach. The connectors become a piece of the company’s own infrastructure rather than part of a vendor’s product.

What it changes about permission is nothing. The standard settles how a connection is described and called. It has no opinion on whether this assistant should be able to issue a refund. That is settled by the account behind the connection and by the operations the connection was built to offer, both of which are somebody’s decision at setup. The standard does help at the point of asking: a system can show an assistant only the operations the account it is using is allowed to perform, so a read-only login is offered a read-only set of options. A connection being easy to make is not the same as it being safe to make, and the first does not answer the second.

What changes once an AI is connected

An assistant that only writes text is cheap to be wrong. You read it, you discard it, you ask again. Connecting it changes that in two ways at once.

The first is reach. A mistake now lands in a system other people use.

The second is that a connected assistant usually reads text written by people outside the company: inbound email, support tickets, web pages, supplier documents. The model takes all of it as one stream and has no dependable way to tell material from instruction, so text inside the material can give it orders. That is prompt injection. Connection is what changes its weight. Disconnected, a hidden instruction gets somebody a wrong paragraph. Connected, it gets whatever the connections allow.

Which means the honest measure of exposure is not the model and not any single connection. It is the set of connections open at the same moment, taken together. An assistant that can read tickets, read the customer database and send email has a much larger answer than the same assistant with only the first, because one instruction can walk through all 3 in order.

So permissions get set against the task rather than against the system. If the job is answering questions about orders, the connection reads orders. Answering a question about an order never requires the ability to change one, and a connection that cannot write cannot be talked into writing by anybody, however the request is worded. Where an action genuinely is the job, it belongs in its own connection with its own gate, rather than as an extra ability quietly added to the reading one.

The same assistant, 2 sets of permissions

Add one connection and the model is unchanged, but the list of things that can go wrong is not. The assistant is the same assistant. Everything that differs sits on the connection.

Example

Let’s say a support assistant answers order queries, connected to the order system with a login that can look orders up and do nothing else. A customer asks where their order is, the assistant looks it up and replies. The worst ordinary day is that it reads the wrong line and gives somebody a delivery date that is not theirs. The customer writes back, someone corrects it, and the cost is one more email. What that version needs is an account restricted to reading, a record of which orders were looked at, and a person reading a sample of the replies.

Now say the business adds one connection so the assistant can issue refunds against an order, because refunds are most of the queue. Nothing about the model changed and the failures are different. A misread order refunds the wrong customer, and the money is out. A customer who writes in often enough learns which wording gets a refund. And because tickets are written by strangers, a line addressed to the assistant inside a ticket is now worth something to whoever sends it: 20 refunds can go out before anybody looks at the day’s total. What this version needs is a person approving before money moves, a cap on the size of a refund the account can issue at all, a record tying every refund to the ticket that caused it, and someone who has thought about the fact that the text triggering it was written by a stranger.

What to ask about anything connected

None of this is settled by how good the model is. A better model reads the CRM more accurately and issues the same wrong refund when a ticket tells it to.

The questions that describe what an AI can actually do inside a business are what it is connected to, whether each of those connections reads or writes, whose account it runs as, and what a person sees before a write happens. They apply the same way to a product the company bought and a tool the team built, and they can be answered by whoever set it up in a few minutes.

They get harder when the assistant stops answering one question at a time and starts choosing its next step from the result of the last, which is what an agent is. The connections are still the answer to what it can do. There are just more steps between the instruction and the action.

Common questions

What is an MCP server?

An MCP server is a piece of software that lets AI assistants use one system, such as a CRM, a database or a file store, through a shared standard called the Model Context Protocol (MCP). It publishes a fixed list of lookups and actions the AI may ask for, runs each request against the real system under an account somebody set up, and passes the result back as text. The AI never touches the system directly, so it can only do what that list and that account allow.

What is the difference between MCP and an API?

An API is the set of operations one system offers to other software, and every system's API is different. MCP is one shared format for offering operations to AI assistants, so a connection built once works with any assistant that supports it. The two usually work together: an MCP server sits in front of a system and calls that system's API when the AI asks for something.

How does MCP work?

With MCP, a system describes what it offers in a standard format, split into things an AI can read and things it can do. The AI assistant sees that list, and when it needs something it writes a request naming one item and its inputs. The MCP server for that system runs the request under a set account and returns the result, which the AI reads before it answers. Anthropic created MCP and in December 2025 gave it to the Agentic AI Foundation, part of the Linux Foundation, and Claude, ChatGPT, Gemini, Microsoft Copilot and Cursor all support it.

Is MCP secure?

MCP sets how an AI asks a system for something, not what the AI is allowed to do. That is set by the account each connection runs under and the list of actions it offers, both chosen by whoever sets it up. The main risk comes when the AI also reads text from outside the company, such as emails or web pages, because instructions hidden in that text can steer it to use any connection it has open. Read-only access where reading is enough, a person approving every action, and a log of each request keep that risk down.

Key takeaways

• A connection is ordinary software. The model writes a request naming a lookup or an action, a piece of software runs it against the real system under a real account, and the result comes back as text the model reads.
• An AI reaches nothing by default. It reaches what somebody connected it to, and only as much of that system as the account behind the connection allows.
• The line that matters is reading against acting, not which system sits on the other end. A read that goes wrong produces a wrong answer. An action that goes wrong changes something that was true.
• Connecting used to be a separate build for every pairing of assistant and system. MCP is the common standard that replaced that, and the major assistants and coding tools speak it.
• The standard settles how a connection is described and called. It settles nothing about what the connection may do. That is the account behind it and the list of operations it was built to offer.
• A connected assistant reading text written outside the company can be given instructions by that text. What one hidden instruction can reach is every connection open at that moment, taken together.
• Match permissions to the task. Read-only where reading answers the question, because a connection that cannot write cannot be talked into writing.
• The useful questions about any AI product are what it is connected to, whether each connection reads or writes, whose account it runs as, and what a person sees before a write happens.