MCP Security and Governance

MCP gives an AI application real reach into your systems — query a database, modify a ticket, send a message. That reach is the whole point, and also the whole risk. An MCP server is a privileged boundary, and the architect's job is to make sure every connection across it is authenticated, scoped, audited, and trusted. Treat MCP security with the same seriousness as any production API gateway.

Diagram of a governed MCP connection passing through authentication, scoping, and audit checkpoints, while an untrusted third-party server is quarantined.

Authenticate and least-privilege every connection

Two questions govern every tool call: who is connecting? and what are they allowed to do?

Authenticate the connection. No anonymous clients. In an Azure shop, require an Entra ID / OAuth token on the transport and reject anything unsigned.
Least-privilege capabilities. A server should expose only the tools an agent needs, and each tool should run with the minimum rights to do its job. Read-only agents get read-only tools; write tools (create_ticket, update_record) are separately gated and ideally require a human-approval step in the host.
Scope per identity and tenant. Carry the end-user or service-principal identity through to the action so row-level security and tenant isolation actually hold — the server, not the model, enforces them.

Audit which tools an agent can reach

You can't govern what you can't see. Maintain an explicit inventory of every server a host connects to and every tool it exposes, and review it like a permission set — because that's what it is. Then log every tool call: who, which tool, what arguments, what result. These audit trails are what let you answer "could this agent have read that table?" during an incident, and they're table stakes for any compliance review. Capability lists should be allow-listed and change-controlled, not discovered ad hoc in production.

The supply-chain risk of third-party servers

This is the failure mode teams underestimate. Connecting your host to a third-party MCP server is granting code you didn't write a foothold inside your AI's decision loop. Specific dangers:

Malicious or compromised servers can return crafted results designed to manipulate the model — a form of prompt injection delivered through a tool response.
Tool descriptions are part of the prompt. A hostile server can hide instructions in a tool's metadata that the model reads and obeys.
Silent changes. A server you trusted yesterday can change its behavior or be taken over.

Defenses: pin and vet the servers you connect to, prefer first-party and signed/verified sources, isolate untrusted servers, and treat every tool result as untrusted data — never let it auto-trigger a privileged action without validation.

How LyraLearn applies this

LyraLearn's own tooling connects only to first-party, authenticated MCP servers with read- scoped capabilities, logs every tool invocation for review, and treats all tool output as data rather than instructions — the same posture Module 3.4 brought to prompt injection, now extended across the whole tool boundary.