How AI connects to company systems

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. It sees the CRM if somebody connected it, and it sees exactly as much as the account behind that connection allows. 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.

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.