Enterprise MCP: wiring agents into the IS without Shadow AI

The real question is no longer “which agent”. It is “how it touches the IS”.

The moment an agent can read mail, create an event, or query a system of record, it leaves the chat sandbox. It becomes an actor in the information system. Yet many early rollouts still rely on home-grown scripts, shared API keys, and throwaway plugins. The result is familiar: tools invisible to IT, accounts that are too powerful, traces nobody can replay. That is the same Shadow AI problem described on the platform side in AI for leaders as a trusted AI layer.

MCP (Model Context Protocol) offers something else. A shared contract for exposing tools to agents: schema, discovery, session. Not another “AI app”, an integration layer that IT and the CTO can govern.

A readable tool contract

Standard schema, discovery, and session: the agent knows what it can call, and the IS knows what was exposed.

Why throwaway scripts and plugins do not hold

A Bash script or an ad hoc plugin wins the PoC. In production it becomes debt. Every team invents its own argument shape, timeouts, and error handling. Nobody shares the same tool inventory. When the agent fails, you cannot tell whether the model misunderstood, the tool changed, or a service account drifted.

MCP makes the boundary explicit. The tool declares what it accepts and what it returns. The client (agent or platform) discovers the catalogue at runtime. The session carries call context. It is not magic, but it is closer to a well-versioned REST API than to a pile of scripts. For agent workflows more broadly, see also Enterprise AI agents.

Real identity, not an omnipotent service account

The classic trap is a service account that can do everything “so the agent works”. Fine in a demo, disastrous in an audit. When a tool acts for a user, the call should carry that identity (OAuth, delegation, limited scopes), not a shared super-key.

MCP does not replace IS IAM. It plugs into it. The goal: an agent that books a meeting does so with the person’s rights (or an explicit role), not with a forgotten vault secret. The CNIL and the GDPR push the same idea from another angle: know who processes what, for which purpose, on which legal basis. An omnipotent service account erases that chain.

Delegation over god-mode

OAuth and per-tool scopes: every call stays tied to a named user or role, not a magic key.

A governed catalogue versus Shadow AI

Without a catalogue, every team wires “its” connector. With an approved MCP catalogue, the platform publishes allowed tools (messaging, calendar, tickets, document read…) and rejects the rest. Same reflex as for SaaS apps: allowlist, review, revoke.

Shadow AI often starts with good intent (save time) and no controlled alternative. A useful MCP catalogue flips the equation: the easiest path becomes the governed path. Workflow automation and agents are not interchangeable; n8n vs AI for leaders still helps pick the right tool. MCP standardises how the agent touches the IS.

Audit: what was called, by whom, with what result

A risk committee does not ask whether the model is smart. It asks which tools ran, on which data, with what outcome, for which user. MCP calls should be logged like the rest of the IS: timestamp, identity, tool, non-secret parameters, status, correlation with the agent session.

Without that, observability stops at the prompt. With it, you can replay an incident, answer an audit, and cut a tool without redeploying the whole platform. Frameworks such as the NIST AI RMF insist on inventory / measure / control. MCP gives a technical hook to hold that loop on the tool side.

First battlefield: messaging and calendar

ERP and document systems will come. The realistic first battlefield is often Outlook (or the equivalent): read / summarise a thread, propose a slot, create an event. Business risk is real, but the perimeter is bounded, IAM already exists, and value shows up quickly for leadership teams.

That is also where you validate the MCP pattern under real conditions: tool server behind enterprise identity, mail/calendar scopes, catalogue review, audit dashboards. Once that foundation holds, expanding to tickets, CRM, or document stores becomes a catalogue problem, not a rewrite of the tool contract.

Conclusion

MCP is not another gadget in the agent stack. It is how you wire agents into the IS with a clear contract, real identity, a governed catalogue, and auditable calls. Without it, every improvised connector recreates Shadow AI. With it, IT keeps control while the business moves.

For the “trusted layer” framing on the platform side, reread AI for leaders as a trusted AI layer. For agent workflow design, Enterprise AI agents.