Topic starter
25/06/2026 12:56 am
TL;DR: Model Context Protocol turns AI tool connectivity into an identity governance problem through tokens, service accounts, and other non-human access paths, according to Apono. MCP servers need tighter ownership, expiry, and revocation controls so each call can be traced and bounded.
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: 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.
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.
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.
Glossary terms: Model Context Protocol, Non-Human Identity (NHI), Standing Privilege, Action Provenance
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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