Topic starter
19/12/2025 11:30 am
TL;DR: Model Context Protocol changes the security problem from discrete API requests to continuous context flow, autonomous tool chaining, and non-human identity behavior that traditional API gateways, OAuth, and static secrets were not designed to govern, according to Aembit. The practical shift is from endpoint protection to runtime identity, context, and policy control.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “MCP vs. Traditional API Security: Key Differences”.
Key questions
Q: What breaks when MCP security is tested like a standard API?
A: Standard API testing misses relationship-based failures such as confused deputy abuse, token passthrough, and trust-boundary violations between clients and servers.
Q: Why do MCP agents increase access risk compared with conventional service accounts?
A: MCP agents can make runtime tool choices and may carry human-derived entitlements, so their effective authority is not fixed at provisioning time.
Q: What are the warning signs that MCP access is not properly controlled?
A: Warning signs include hard-coded credentials in server files, broad tool permissions, no per-tool ownership, and logs that cannot show which agent made a call.
Practitioner guidance
- Model MCP as a runtime identity problem Classify every agent, server, and tool as a governed non-human identity and document what authority each one can exercise at runtime.
- Separate inherited and native permissions Record which entitlements belong to the agent itself and which are inherited from the human who initiated the workflow, then review both before production use.
- Move authorisation to decision time Evaluate each tool invocation with current context, posture, and identity state instead of relying on roles or scopes assigned before the session began.
Bottom line: MCP changes the security problem from request handling to workflow governance, because the relevant unit of control is the agentic chain rather than the single API call.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/10/2026 9:23 pm
Continuous context is the new access primitive in MCP. The older assumption is that security can inspect a request, decide, and move on. That assumption fails when the actor carries state across multiple tool invocations and the security decision must follow the context, not just the endpoint. The implication is that governance now has to account for how identity, data, and intent travel together through a workflow.
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.
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Should security teams use API gateways alone to control MCP access?
A: No. API gateways can still validate schemas and rate-limit calls, but they do not judge agent intent, blended authority, or context integrity. MCP needs identity-first enforcement at runtime, with policy decisions tied to the agent, the human-derived attributes it carries, and the specific tool invocation.
👉 Read our full editorial: MCP changes the security model for agentic workflows and access