Standard Tool Connections for AI, and the Permissions Problem They Create

Every AI tool that does something useful needs to reach data that lives somewhere else — a database, a ticketing system, a document store, an internal API. For a while, every integration was bespoke: custom glue between one model and one system, written once, maintained by whoever wrote it.

That does not scale, and the industry has been converging on standard ways to describe and expose tools to models. The details will keep moving; the architectural questions are stable and worth thinking about now.

What a tool-connection layer provides

Three things, whatever the specific protocol.

Discovery. A model can ask what tools are available and receive machine-readable descriptions — names, parameters, what each does. No hardcoded list.

Invocation. A uniform way to call a tool and receive a structured result, so the model does not need to know whether it is talking to a database or a REST API.

Context. A way to expose resources — documents, records, files — that the model can read without a bespoke retrieval pipeline for each source.

The benefit is combinatorial. Without a standard, connecting five models to ten systems is fifty integrations. With one, it is fifteen.

The security consequence people miss

A standard connection layer makes it dramatically easier to give a model access to a system. That is the point, and it is also the risk.

Previously, each integration required deliberate engineering, and that friction functioned as an accidental review step. Someone had to think about what the integration exposed. When adding a data source becomes a configuration entry, that step disappears, and access accumulates without anyone deciding it should.

Two consequences follow.

Permissions must be designed, not inherited. The instinct is to connect a tool with the credentials that already exist — often an account with broad access because it was created for a human. The model then inherits everything that human could do. Every connection deserves its own least-privilege credential.

Composition creates capability nobody granted. A tool that reads a shared drive and a tool that sends email are each unremarkable. Together they are an exfiltration path. Reviewing tools individually will not surface this; you have to look at the set.

Where the trust boundary sits

Any tool that returns content originating outside your control returns untrusted data. A web fetcher, an email reader, a ticket system, a shared document store — all of these can carry text crafted to influence the model.

The practical rule from this: partition your tools by trust level, and do not let an agent that has read untrusted content also hold high-consequence tools in the same session. A connection standard makes it easy to grant everything at once. Resist that specifically.

What to do now

Standards in this area are young and will change. What is unlikely to change:

• Every connection gets its own credential, scoped to the minimum it needs
• Read-only by default; write access is a separate, deliberate decision
• Tool invocations are logged with arguments, independent of any conversation log
• Tool sets are reviewed as combinations, not as individual entries
• Untrusted-content tools and high-consequence tools stay in separate contexts

Those hold regardless of which protocol wins, which is a reasonable definition of the part worth investing in.