Notifications
Clear all
Topic starter
02/08/2026 12:15 pm
TL;DR: MCP moved from niche spec to enterprise interface layer in a year, with adoption driving privileged tool access, visibility gaps, and a new security category, according to Akto. The real issue is not protocol popularity but the governance assumption that agents can safely inherit human-paced controls.
NHIMG editorial — based on content published by Akto: One Year of MCP: How it Became the Foundation for Enterprise Agentic AI
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
Q: Why do MCP-based agents create more risk than ordinary API integrations?
A: Because the agent is choosing actions, chaining tools, and preserving context across steps.
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 owner Create a current register of all MCP servers, the systems they reach, the teams that created them, and the identities they depend on.
- Scope every tool to a named business action Replace broad tool permissions with explicit action boundaries that reflect what the tool should do in production, not what it could do in theory.
- Remove hardcoded secrets from MCP configurations Scan server configs, local development environments, and CI pipelines for embedded tokens, then rotate and replace them with managed secrets or workload identity patterns.
What's in the full article
Akto's full blog covers the operational detail this post intentionally leaves for the source:
- Specific examples of MCP server deployment patterns across IDEs, internal platforms, and CI/CD workflows
- The article's own breakdown of how developers and security teams split on governance versus enablement
- Akto's description of its MCP Security category and how it frames discovery, permissions, and oversight
- Additional references to related resources on MCP governance, attack matrices, and AI agent security
👉 Read Akto's analysis of how MCP became the foundation for enterprise agentic AI →
MCP as enterprise plumbing: what it means for agentic AI security?
Explore further
02/08/2026 1:17 pm
MCP security is now an identity governance problem, not just a developer tooling issue. Once MCP becomes the standard interface for agentic workflows, the security question shifts from integration convenience to authority management. The server is no longer a passive connector. It becomes a delegated actor that can read, write, and execute across enterprise systems, which means IAM, PAM, and NHI governance now intersect at the protocol layer.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 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: Who should be accountable for risky MCP actions in enterprise environments?
A: Accountability should follow the full delegation chain, not just the token holder. That means the delegating human, the agent or client, the policy owner, and the approver must all be visible in the audit record when a high-impact action occurs. Without that chain, compliance and incident response lose the evidence needed to explain why the action happened.
👉 Read our full editorial: One year of MCP shows why agentic AI needs governance
