Secure MCP integration
Copilot through a deliberately narrow MCP boundary.
AI clients become operationally useful when they can reach real systems. They also create a new integration boundary that needs to be narrower, more legible, and easier to control than unrestricted access to those systems.
- Enterprise case
- Hailey HR / internal systems / Copilot
- Product case
- Nine selected Autotask tools
- Identity
- Microsoft Entra authentication
01
Expose a capability, not an entire system.
For an enterprise use case, I built the MCP integration layer connecting Hailey HR and internal systems to a Copilot agent. The customer use case was accepted into Microsoft's Cloud Accelerate Factory, where that integration boundary informed the architecture work.
The important design decision was to make the boundary explicit: the agent received defined capabilities rather than broad, implicit access to the underlying systems.
02
Apply the same principle to a self-hosted product.
ATEM is a separate Bragi product that exposes nine deliberately selected remote Autotask tools through an Entra-authenticated MCP boundary. Local and higher-risk operations stay outside the Microsoft 365 allowlist.
- Nine selected remote tools rather than unrestricted access
- Microsoft Entra authentication
- Self-hosted deployment
- Local and higher-risk operations kept outside the allowlist
03
Design for inspection and change.
A useful MCP boundary should make it clear which tools exist, where authentication occurs, and which operations remain unavailable. That makes the integration easier to review and gives future changes an obvious place to be evaluated.
The safest useful integration is not the one with the most tools. It is the one whose permitted capabilities can be understood and defended.