How does MCP work, and how do you govern AI tool access?

MCP is an open standard plug between AI apps and tools. The host, like Claude, ChatGPT or Copilot, contains an MCP client. That client sends MCP messages to an MCP server, and the server wraps a real system, here a CRM, by making API calls on its behalf.

The assistant first asks the MCP server which tools exist, and gets back get_customer and update_phone. Those are the only options the model sees. Then it picks get_customer for customer 42. The server queries the CRM, receives the record, and returns it as a tool result. The model never touches the CRM directly.

The model never touches the CRM. It only asks. The MCP server holds the credentials and decides what happens, so that's where security has to live.

A tool request doesn't go straight to the CRM. First, the host asks the user to confirm. Then the server checks the OAuth token's scopes. Finally, the CRM applies its own account permissions. That's defense in depth, and any one of those layers can stop the call.

Each right becomes a tool design choice. Reading is get_customer, allowed automatically. Writing is update_phone, behind approval. Delete simply has no tool. Hints like readOnly or destructive help hosts warn users, but they don't enforce anything. The server does that.

The model tries to call delete on customer forty-two, but the server exposes no delete tool or scope. What happens?

The call fails and nothing changes. The model can only request tools the server offers, and the server checks scopes before acting. With no delete tool or scope, there is nothing to execute. The host also has no direct path to the CRM, so the request simply fails.

For customer 42, the assistant asks the user to approve the phone update. Once they approve, it calls update_phone, and the MCP server writes to the CRM. Then a delete is attempted, maybe from a confused or prompt-injected model. The server denies it, because no scope was ever granted. Nothing gets deleted. The server enforces that, not the model's good behavior.

For a whole organization, you can route every assistant through one MCP Gateway. It verifies the user against SSO identity, only forwards calls to approved servers, and records each call in the audit log. A gateway is optional, but it makes this control much simpler to manage.

Turn the pattern into policy. Vet MCP servers like any third-party code, and allowlist only approved ones. Use per-user tokens, never a shared admin token. Keep read-only and write servers separate, and review the logs regularly.

Each platform gives admins some switches: Claude and ChatGPT manage connectors at the organization or workspace level, and Copilot uses GitHub org policy. Plans and features change quickly, so check current docs. These switches never replace server-side scopes.

The assistant only asks. The MCP server holds the keys, and it decides what actually happens. So before you enable any assistant, design the tools and scopes first: expose only what's needed, give least privilege, and let the server enforce it.