SAS explains MCP to enterprises: useful standard, not a security one

Almost two years after Anthropic released it as an open standard in November 2024, Model Context Protocol now has its own reference guide on the website of SAS, one of the analytics vendors with the most weight in banking, insurance and the public sector. The piece, Model Context Protocol: What it is and why it matters, went up on 16 October and contains one sentence that deserves more attention than the rest: MCP "is not a security governance or compliance framework".

Given who is saying it, that is no minor caveat. SAS sells mostly to regulated industries, and the fact that its flagship explainer on MCP devotes an entire section to what the protocol does not solve says a lot about the questions it is getting from its customers' risk committees.

What the guide explains

The SAS article defines MCP as an open standard that sets how AI applications connect to external tools, data sources and systems through a common interface. It uses the now familiar USB-C port comparison and breaks the architecture down into four pieces:

1. The agent, which reasons and decides which data or tools it needs.
2. The MCP client, which lives inside the host, translates that intent into the protocol and manages the connection.
3. The MCP server, described as a stateless bridge that exposes capabilities in a controlled way.
4. The enterprise systems behind it: databases, CRM, ERP, analytics platforms, APIs and repositories such as GitHub or GitLab.

The guide also clears up a common confusion: MCP does not replace APIs, it "typically sits on top of" them. It adds a layer designed so that a model can discover which tools are available and how to call them, without every integration being a custom build.

On the institutional side, SAS recalls two milestones. Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation in December 2025, and since launch OpenAI, Microsoft and GitHub have announced support, integrations or contributions to the protocol. In other words, nobody is debating any more whether MCP is a de facto standard; the conversation has moved on to how to deploy it safely.

Use cases by industry

The most useful part for anyone who has to justify a project to management is the industry rundown. In healthcare, agents that query patient records, clinical guidelines and laboratory databases while respecting access boundaries. In banking, credit risk evaluation, fraud detection, audits and compliance with controlled access to documents and databases. In the public sector, eligibility checks, investigations and resource allocation over confidential information. In insurance, integration with business rules systems so that underwriting decisions are made inside the insurer's own environment.

It is worth reading with the knowledge that this is also a product page. SAS uses it to present its SAS Viya MCP Server, which connects agents to its analytics and decisioning capabilities, and the MCP integration in SAS Retrieval Agent Manager. Nothing wrong with that, but readers should separate the explanatory part from the commercial one.

What the protocol leaves in your hands

The governance section is what makes the read worthwhile. According to SAS, the organisation remains responsible for identity management, authentication and authorisation, data governance and regulatory compliance, auditability and forensic trails, and human approval workflows for sensitive actions. The guide also cites risks specific to agentic systems such as "goal misalignment, tool-instruction abuse and cascading trust failures".

Ramya Mopivedi, Senior Product Manager at SAS, sums it up: the protocol addresses "one of the biggest challenges in enterprise AI: how to make AI systems interact with live operational environments without sacrificing governance, safety or clarity". The key lies in the nuance: it addresses the problem, it does not solve it on its own.

Who it is useful for

For technology and data leads in regulated industries who are starting to evaluate agents, the guide is a good bridge document: it explains the architecture without excessive jargon and puts on the table the responsibilities that do not go away. For technical teams already working with MCP servers, whether in `claude_desktop_config.json` or from Claude Code, it adds little that is technically new, but it helps align expectations with business and security teams.

In the MCP servers we have built for clients, the real work rarely lies in exposing tools. It lies in deciding what is not exposed, which credentials each call runs with, what gets logged and which actions require human confirmation. The protocol gives you the plug; you design the fuse box.

Having a vendor with SAS's customer base put this in writing helps that conversation reach risk committees sooner, which is where these projects tend to stall. We think it is worth reading precisely because of what it admits MCP does not do.