Autonomy
Model Context Protocol (MCP)
Also called: MCP
Definition
The Model Context Protocol is an open standard for connecting AI systems to tools and data sources through a consistent interface rather than bespoke integrations.
MCP matters commercially because it lowers the cost of giving an agent access to a system — which is exactly why it deserves governance attention. Standardised connection makes capability easy to add and easy to add carelessly, since the same ease that helps a legitimate integration also helps an unreviewed one slip through. The interesting question is not whether to adopt it, but who approves each server an agent is allowed to reach, and on what basis.
Standardisation cuts both ways
The same interface that removes months of integration work also removes the friction that used to function as an informal control, because a bespoke integration required enough engineering effort that someone usually had to sign off on it along the way. Connection review has to become deliberate rather than incidental, precisely because the technical barrier that used to force a conversation about whether a connection was appropriate has now been engineered away by design, for good reason, but with a governance gap left behind.
Treat servers like vendors
A connected server sees the data you route through it and can influence agent behaviour, which makes it functionally a third party with access to your systems, even if it was set up by an internal engineer in an afternoon. Apply the diligence you would apply to any third party with that access — who operates it, what their security posture is, what happens to the data that passes through — rather than treating it as a purely internal technical decision with no vendor-risk dimension.
Scopes should default to narrow and expand deliberately
Because MCP makes adding a new connection so easy, the natural drift is toward granting broad scopes upfront to avoid having to come back and request more later. That convenience works directly against the delegation-boundary discipline every agentic deployment needs, and it is worth resisting: start every new server connection with the narrowest scope that lets the intended task work, and expand only when a specific, reviewed need arises, rather than provisioning for hypothetical future use cases.
In practice
- Maintain an inventory of connected servers and their scopes
- Require named approval before an agent gains a new connection
- Prefer read-only scopes until the workflow has proven itself
- Apply vendor-level diligence to any externally operated MCP server
