Notifications
Clear all
Topic starter
12/06/2026 9:15 pm
TL;DR: MCP standardises how agentic applications discover tools, call resources, and authenticate to remote servers, while also surfacing security pitfalls around OAuth2, prompt injection, and trust boundaries, according to Riptides. The governance question is no longer whether agents can use tools, but which identities, policies, and approval paths constrain them.
NHIMG editorial — based on content published by Riptides: MCP: A Quickstart Guide
Questions worth separating out
Q: How should security teams govern access to MCP servers in production?
A: Security teams should govern MCP servers as production access paths with explicit ownership, allowlists, and lifecycle review.
Q: Why do MCP-based agents create new trust-boundary problems?
A: MCP-based agents create trust-boundary problems because tool selection happens at runtime and may span local and remote servers.
Q: What do security teams get wrong about OAuth2 in agentic workflows?
A: Teams often assume OAuth2 makes the whole path safe once the client authenticates.
Practitioner guidance
- Inventory every MCP trust boundary Map each local and remote server, the credentials it receives, and the backends it can reach.
- Require explicit allowlists for agent connections Configure which servers an agent may connect to, and avoid hardcoding those choices into application code.
- Validate token acceptance across the full path Test that the OAuth2 token issued to the MCP client is accepted by the MCP server and by every backend API the server needs.
What's in the full article
Riptides's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step MCP client and server setup examples for local and remote deployments
- Example mcp.json configuration patterns for connecting agents to multiple tool servers
- Transport-specific guidance for stdio, Streamable HTTP, and SSE compatibility
- Practical notes on using mcp-remote to bridge stdio clients with remote servers
👉 Read Riptides’s guide to MCP architecture, OAuth2, and security pitfalls →
MCP and agentic AI trust boundaries: are your controls ready?
Explore further
12/06/2026 11:11 pm
MCP turns tool access into a runtime identity decision, not a static integration choice. The guide’s core architecture lets an LLM select tools dynamically from a server catalogue, which means privilege is exercised at the moment of execution rather than at deployment time. That shifts control from app configuration to session behaviour. For identity governance, the implication is that access policy now has to understand runtime selection paths, not just service endpoints.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can organisations reduce prompt injection risk in MCP deployments?
A: Organisations should validate both user prompts and tool responses before they influence the model’s next action. The goal is to stop untrusted input from steering tool calls or shaping later decisions. Add middleware, restrict the available server set, and ensure sensitive actions require policy checks outside the model itself.
👉 Read our full editorial: MCP’s security model exposes new trust gaps for agentic AI
