Notifications
Clear all
Topic starter
19/08/2026 3:49 pm
TL;DR: MCP is turning AI tool access into a standardized, self-discoverable layer that changes how APIs are exposed and governed, according to Equixly’s analysis of MCP architecture and security trade-offs. The practical issue is not whether MCP replaces APIs, but whether access control, authentication, and secret handling keep pace with agentic discovery and orchestration.
NHIMG editorial — based on content published by Equixly: How MCP servers challenge traditional API security models
By the numbers:
- In December 2025, Anthropic reported more than 10,000 active public MCP servers, showing how quickly the protocol is spreading across tool integrations.
- According to Equixly, 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Equixly also found that only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP servers create more risk than traditional APIs?
A: MCP servers create more risk because they centralize access, make tools discoverable at runtime, and often sit close to the secrets that authenticate downstream calls.
Q: What breaks when MCP tool permissions are scoped too broadly?
A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role.
Practitioner guidance
- Inventory every MCP server and connected tool Map each server to the downstream APIs, service accounts, tokens, and data sources it can reach.
- Remove hard-coded secrets from MCP configuration Move credentials out of server config files and into managed secret stores with rotation, revocation, and audit logging.
- Scope tool permissions per use case Apply least privilege at the tool level so an agent can call only the functions it needs.
What's in the full article
Equixly's full blog post covers the operational detail this post intentionally leaves for the source:
- Protocol-level analysis of how MCP servers translate tool discovery into runtime execution
- Specific security findings on command injection, SSRF, and path traversal in tested MCP implementations
- Practical testing guidance for validating MCP server exposure before agents are allowed to use them
- Details on early-access support for MCP testing within Equixly's platform
👉 Read Equixly's analysis of how MCP servers challenge traditional API security models →
MCP servers and API security: what changes for practitioners?
Explore further
19/08/2026 4:25 pm
API security is no longer just about endpoints. It now includes the machine identity layer that brokers tool discovery and execution. MCP changes the trust boundary because an AI client can discover capabilities dynamically rather than operate against a fixed developer-defined path. That means access governance has to cover the server, the secret, and the delegated action together. Practitioners should stop treating MCP as a transport detail and start treating it as an NHI control point.
A question worth separating out:
Q: Who is accountable when an AI agent takes action through an MCP server?
A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.
👉 Read our full editorial: MCP servers are forcing a rewrite of API security assumptions
