TL;DR: Model Context Protocol shifts security from static API transactions to agent-driven workflows where context, identity, privilege, and supply chain risks can cascade across tools and services, according to Aembit. Traditional gateway-centric controls were not built for dynamic agent behavior, so identity-first and runtime policy become the real control plane.
NHIMG editorial — based on content published by Aembit: Model Context Protocol security vulnerabilities and defensive strategies
Questions worth separating out
Q: How should security teams implement MCP security in agentic AI workflows?
A: Security teams should treat MCP as an identity-first control problem.
Q: Why do MCP workflows complicate traditional API security models?
A: MCP workflows complicate API security because the risk is no longer limited to a single request and response.
Q: What breaks when context is not validated in MCP environments?
A: When context is not validated, poisoned or manipulated data can drive unsafe downstream actions.
Practitioner guidance
- Replace static credentials with workload identity Use cryptographic workload identity for MCP participants and issue short-lived access only after verification.
- Validate context at every trust boundary Inspect context source, schema, size, and expected structure before an agent passes data to another tool.
- Tighten delegation scope for tool-to-tool calls Limit which agent or tool can receive a token, what it can do, and how long it remains valid.
What's in the full article
Aembit's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for replacing static API keys with secretless workload identity in MCP environments
- Specific examples of transport, authentication, and context validation gaps across agent-to-tool chains
- Runtime policy and logging considerations for teams that need to investigate or audit MCP actions
- Deployment patterns for securing MCP servers, tools, and hybrid cloud workflows without relying on static credentials
👉 Read Aembit's guide to MCP security vulnerabilities and identity-first defenses →
MCP security gaps for agentic AI workflows: what teams miss?
Explore further
MCP is really an identity and delegation problem, not just a protocol problem. The article shows that once agents start chaining tools and passing context, the security boundary moves away from the API and into runtime identity decisions. That aligns with OWASP-NHI and Zero Trust thinking, because the question is no longer whether a request is valid in isolation. The practitioner implication is that MCP controls must be built around verified workload identity, scoped delegation, and boundary enforcement across every hop.
A few things that frame the scale:
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
- Only 44% have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
A question worth separating out:
Q: How can organisations reduce privilege escalation in MCP tool chains?
A: Organisations reduce privilege escalation by giving each agent and tool only the permissions needed for its immediate task, then revoking access when the task ends. They should also constrain token reuse and session scope so one compromised participant cannot become a launchpad for broader access across the workflow.
👉 Read our full editorial: MCP security gaps show why traditional API models fall short