Notifications
Clear all
Topic starter
02/08/2026 9:44 am
TL;DR: Model Context Protocol gives AI agents a standard way to reach enterprise tools and data, but it also creates new exposure across identity, authorization, prompt integrity, and shadow infrastructure, according to Salt. The governance gap is now the lack of visibility and control around agent-to-tool connectivity, not the protocol itself.
NHIMG editorial — based on content published by Salt: Model Context Protocol security and enterprise AI governance
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
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 environments increase identity governance complexity for AI agents?
A: MCP turns model-tool interaction into a repeatable identity event, which means access, logging, and approvals must work at the capability level rather than at the application level.
Q: What breaks when MCP servers are not registered centrally?
A: Unregistered servers create shadow deployment.
Practitioner guidance
- Discover and inventory every MCP server Build a live inventory across endpoints, developer workstations, cloud instances, containers, and CI/CD systems.
- Apply least privilege to each tool, client, and downstream system Separate read, write, and execution rights so a documentation server cannot modify repositories and an analytics server cannot touch cloud infrastructure.
- Require explicit authorization for every agent-driven action Validate the user, agent, client, server, and requested action before a tool call is allowed to proceed.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step MCP server discovery and inventory guidance for production environments
- Practical examples of authentication, scope control, and audit logging across agent-to-tool access
- Detailed discussion of tool poisoning, prompt injection, and confused deputy risk patterns
- Security review considerations for third-party MCP servers before production use
👉 Read Salt's analysis of Model Context Protocol security and enterprise AI governance →
Model Context Protocol governance: are your controls keeping up?
Explore further
02/08/2026 12:37 pm
MCP creates a governance gap because it standardizes connectivity before it standardizes trust. The protocol makes agent-to-tool integration easy, but it does not by itself solve authentication, consent, scope control, or auditability. That means enterprises can scale access faster than they can prove who authorized what, and that is a classic identity control debt problem. Practitioners should treat MCP as a control plane that needs governance, not as a convenience layer.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, while 48% still lack that visibility, according to the same research.
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: Model Context Protocol security exposes a new governance gap
