Copilot Beyond Microsoft: Governed MCP for Your Whole Stack

Microsoft Copilot has the best starting position of any enterprise assistant, and it is not close. It is already inside Outlook, Teams, SharePoint and Excel, already authenticated against Entra ID, and already covered by licences most large organisations have bought.

Inside that estate, it is genuinely strong. The problem is that the estate is not where most of the work lives.

Your incidents are in a ticketing system. Your customer truth is in a CRM. Your numbers are in a warehouse. Your code is in a Git host. Your deployments are somewhere else again. A Copilot agent that can read the email about the outage but cannot open the incident is doing half a job, and it is the less useful half.

The gap is reach, and the usual fix does not hold

The standard response is to wire a few MCP servers to the non-Microsoft systems and document how to connect them. It works on day one. It degrades from day two.

A pasted configuration has no relationship to your identity system. It does not know that someone changed cost centre, that a data source is now restricted to a smaller group, or that a connector endpoint moved. Every one of those changes becomes a broadcast and a set of manual actions, and the actions never fully complete.

The result is a fleet where the honest answer to "which systems can this person's agent reach" is "whatever they pasted, whenever they pasted it". For an organisation that has invested years in getting Entra groups right, that is a strange thing to accept.

Entra groups as the assignment mechanism

Palma assigns connectors per person by IdP group. If you run Entra ID, the groups you already maintain become the control surface for agent capability. Okta works the same way.

There is no per-user setup and no credentials on laptops. When a Copilot agent connects to the gateway, the MCP initialize handshake returns the tools and skills that person is entitled to at that moment. The skill-set cache runs a 30-second TTL with push invalidation on commit, so an entitlement change is live within seconds.

Install policy modes — open, whitelist or restricted — let a regulated function and an exploratory one run different rules without separate deployments.

Reach is necessary. Method is what makes it useful.

Connecting the ticketing system is the easy half. The harder half is that an agent with access to eight systems now has to decide which one to touch, in what order, and what constitutes a correct result.

A tool is a verb: "create the ticket", "post the update", "pull the report". A skill is the playbook that says when and how to use the verbs it already has. Which system is authoritative for customer status. Which check runs before you notify anyone. What the finished summary contains. Which cases stop and escalate.

That is not model capability. It is your organisation's process, and it exists today in the heads of a small number of people. A skill makes it distributable.

Four surfaces for discovery

• skill:// resources with an index.json discovery manifest.
• Five meta-tools: search_skills, load_skill, save_skill, suggest_skill_improvement, skill_feedback.
• MCP prompts named skill__<name>.
• A Skills section injected into the initialize handshake instructions, capped at twelve with a "+N more" tail.

search_skills is substring matching, so consistent naming in your library is worth the effort. The point of four surfaces is that discovery does not depend on a client behaving in one particular way.

The guardrails

• Immutable, content-hashed versions. What ran is exactly retrievable.
• Only scanner-passed versions are ever served.
• Secrets are stripped from skill content before a version is stored.
• Private, shared and public visibility tiers. Personal skills serve only their owner and are off by default per tenant.
• A tool reference in a skill documents a dependency; it never grants access to the tool.
• A skill that requires a tool cannot be attached directly to a space — it travels in a pack, so the playbook never lands without the access it assumes.

Why not build this into the Microsoft layer

Because the same work would then have to be done again for the next client, and there will be a next client. Engineering will want a coding agent. A business unit in Europe will run something else for data residency reasons. A team will pilot a specialised assistant and it will stick.

Serving capability over MCP makes the connector client-agnostic. The same connectors, skills and policies follow the person into whichever assistant they open. Switching clients does not mean re-approving, re-installing or re-auditing anything, and there is no SDK to adopt or per-client integration work to fund.

That is also the honest answer to the lock-in question a CIO should be asking about Copilot. Standardising on Copilot for the Microsoft estate is a reasonable decision. Building your entire agent capability layer inside it is a decision that gets expensive to reverse. Keeping the capability layer on an open protocol keeps the client choice reversible.

Palma is a Silver member of the Agentic AI Foundation and a member of the Linux Foundation, and builds on MCP rather than a proprietary connector format.

The practical framing

Copilot already knows your email, your documents and your calendar. Governed MCP tells it about everything else, scoped to the person, current as of this session. Skills tell it how your company does the work rather than how a generic assistant would.

Neither of those is a model upgrade. Both are supply-chain decisions about capability, and both need to be live rather than pasted.