Notifications
Clear all
Topic starter
21/08/2026 4:54 pm
TL;DR: MCP servers reduce direct model access, but they also concentrate trust, permissions, and audit responsibility at the point where AI agents reach into tools and data, according to Xygeni. The core issue is not protocol syntax but governance: once context and actions flow through a shared control layer, weak scoping, logging, or review turns AI integration into an identity and access problem.
NHIMG editorial — based on content published by Xygeni: Why MCP servers matter in AI projects
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern MCP servers used by AI coding assistants?
A: Treat MCP servers as privileged trust boundaries, not simple data sources.
Q: Why do MCP servers increase non-human identity risk so quickly?
A: MCP servers connect directly to enterprise services using credentials such as API keys, tokens, and service accounts, so every new deployment expands the number of identities that can reach sensitive systems.
Q: What do teams get wrong about AI agent access in MCP environments?
A: Teams often focus on the agent interface and ignore the identity objects that actually authorize actions.
Practitioner guidance
- Map every MCP server to an identity owner Assign explicit ownership for the service accounts, API keys, and tokens that authenticate MCP traffic.
- Split broad MCP functions into narrow trust zones Separate servers by domain, tool class, or data sensitivity so one workflow cannot inherit another workflow's privileges.
- Instrument request-level logging for AI context access Record which model or workflow requested context, what data was returned, and which policy decision approved it.
What's in the full article
Xygeni's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for building an MCP server with tighter access boundaries and safer request handling.
- Practical implementation advice on logging, validation, and access controls for production AI workflows.
- Security coverage around the code, dependencies, IaC, and CI/CD layers that support MCP deployments.
- The vendor's own explanation of how its tooling fits around MCP without replacing the protocol itself.
👉 Read Xygeni's guide to MCP servers and Model Context Protocol security →
MCP servers and AI agents: are your controls keeping up?
Explore further
21/08/2026 5:11 pm
MCP governance is really NHI governance in disguise. The protocol changes how context is requested, but it does not change the underlying truth that access is still mediated by identities, secrets, and entitlement scope. Once AI workflows touch internal systems, the governing question becomes which non-human identities can reach which data, through what server, and with what evidence. Practitioners should stop treating MCP as a model feature and treat it as an access boundary.
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, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- 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: How do security teams decide when an MCP deployment is production-ready?
A: A deployment is production-ready when identity is centralized, access is group-scoped, tool calls are logged, revocation is tested, and sensitive data is filtered before it reaches model context. If those controls are missing, the system may be functional but it is not yet governable.
👉 Read our full editorial: MCP servers are expanding AI agent attack surface and trust risk
