Topic starter
25/06/2026 2:48 pm
TL;DR: MCP standardises how AI agents connect to tools and data, but it also expands trust boundaries, introduces context-injection and privilege-escalation risks, and demands continuous identity verification and auditability, according to Aembit. The security problem is no longer integration convenience, but whether existing IAM and NHI controls can govern runtime tool use by autonomous systems.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “What is MCP Security: A Complete Introduction”.
Key questions
Q: How should security teams govern MCP model-agent interactions?
A: Security teams should govern MCP by treating the model-to-agent boundary as an authorization point, not just an integration point.
Q: Why do MCP-based assistants increase the risk of privilege escalation?
A: Because they can combine prompt-driven behaviour with real tool execution and inherited access.
Q: What breaks when AI agents rely on long-lived API keys?
A: Long-lived keys turn a single leaked secret into persistent authority, and agents create more places for that secret to leak through prompts, logs, cache layers, and tool outputs.
Practitioner guidance
- Define MCP workload identities Issue distinct identities for agents, servers, and tools so each participant can be authenticated and traced independently across sessions.
- Replace brittle secrets patterns Eliminate hardcoded API keys and other long-lived credentials from agent integrations, then map every remaining secret to an owner and revocation path.
- Enforce per-invocation authorization Evaluate every tool call, capability discovery step, and context handoff against policy rather than relying on a one-time session grant.
Bottom line: MCP changes the governance problem from integration convenience to runtime control over non-human actors.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
25/06/2026 3:58 pm
MCP security is now an identity governance problem disguised as an integration pattern. The protocol standardises agent-to-tool communication, but standardisation does not create trust. Once agents can discover, request, and chain tool use at runtime, the core question becomes who or what is authorised to act at each step. That pushes MCP into the same governance domain as NHI, workload identity, and privileged access, not into a narrow API-security box.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.
👉 Read our full editorial: MCP security exposes the identity gaps in agentic AI workflows
This post was modified 4 days ago by NHI Mgmt Group