Topic starter
25/06/2026 12:56 am
TL;DR: MCP standardises how AI apps connect to tools and data, but Apono’s analysis shows that the protocol also expands NHI exposure through standing tokens, over-scoped access, and weak auditability. The governance problem is not the protocol itself, but the identity controls around it.
Editorial analysis by NHI Mgmt Group, based on content published by Apono: “7 Cybersecurity Concerns Related to The MCP Protocol”.
By the numbers:
- 20% of organisations experienced breaches tied to unauthorized AI tools, with each incident costing up to $670,000 on average.
Key questions
Q: What breaks when MCP access is left on long-lived tokens?
A: Long-lived tokens assume access is stable enough to review later, but MCP workflows often involve temporary, multi-step delegation.
Q: Why do MCP deployments create audit and accountability gaps for AI agents?
A: Because the protocol can hide who invoked the tool, which context was used, and what data moved downstream unless logging is designed into the control path.
Q: How should security teams govern NHI access when exposing internal tools through MCP?
A: Treat each MCP server as a governed NHI boundary.
Practitioner guidance
- Map every MCP credential to an owner and expiry Inventory API keys, service accounts, and OAuth tokens used by MCP servers, then attach lifecycle ownership, intended scope, and a removal trigger for each one.
- Bind tool access to the requesting identity context Require each MCP request to carry validated tenant, user, or agent context so the server can enforce scope before any downstream action is executed.
- Instrument invocation-level audit logs Log the model, tool, parameters, response metadata, and timestamp for every MCP call, then route the records into your SIEM for correlation.
Bottom line: MCP turns AI tool connectivity into an identity governance problem because the protocol depends on tokens, service accounts, and other non-human access paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:02 am
MCP is not the governance problem. Standing machine access is. The protocol simply makes the access path easier to wire up and harder to ignore. The real failure is that many programmes still treat model connectivity as integration plumbing rather than as a governed NHI estate. Practitioners should reframe MCP adoption as an identity lifecycle problem, not a tooling convenience problem.
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.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is the difference between an MCP integration and a governed AI access model?
A: An MCP integration only proves that the tool connection works. A governed AI access model also proves that the right identity is calling the right tool, with the right scope, for the right duration, and with traceable evidence after the fact.
👉 Read our full editorial: MCP server security creates new identity governance gaps for AI agents