Notifications
Clear all
Topic starter
08/06/2026 4:34 pm
TL;DR: MCP adoption is accelerating because developers want a single abstraction layer for AI tools, and security teams see a path to centralise authentication, authorisation, and auditing at the control plane, according to Astrix Security. The governance challenge is that policy can only stay consistent if the MCP layer becomes the authoritative identity boundary for agent actions, not just an integration shim.
NHIMG editorial — based on content published by Astrix Security: MCP can transform from problem to solution for AI identity governance
Questions worth separating out
Q: How should security teams govern AI agent access through MCP?
A: Treat MCP as the decision layer for identity, not a transport convenience.
Q: When does MCP create more risk than it reduces?
A: MCP creates more risk when it centralises access without centralising governance.
Q: What do teams get wrong about AI agent identity and MCP?
A: Teams often assume that a protocol layer automatically solves governance.
Practitioner guidance
- Define MCP as a governed identity boundary Map every MCP server to an enterprise control owner, an approved policy source, and a logging destination before letting agents use it in production.
- Replace direct API keys with proxy identities Issue signed, scoped identities for agent requests and tie them to a human owner or workload record so access can be revoked without hunting through tool configurations.
- Enforce request-level authorisation Require the MCP layer to evaluate policy on every tool call, including step-up approval for unusual actions, sensitive data access, or cross-domain requests.
What's in the full article
Astrix Security's full blog post covers the operational detail this post intentionally leaves for the source:
- How their survey respondents are thinking about MCP rollout, governance pressure, and security readiness in more concrete terms.
- The specific pattern they describe for MCP gateways, signed tokens, and role mapping across tool requests.
- The examples of how teams are tying MCP tool access to enterprise IAM systems and logging workflows.
- The future-facing security features the article says are still maturing in the MCP ecosystem.
👉 Read Astrix Security's analysis of MCP as an AI identity control plane →
MCP as an IAM overlay for AI agents: what changes for teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
08/06/2026 6:16 pm
MCP is becoming an identity boundary, not just a developer convenience layer. The central issue is where control lives. If authentication, authorisation, and logging are pushed into the MCP layer, organisations can finally govern AI agent access as a coherent identity problem instead of a collection of tool-specific exceptions. That makes MCP relevant to IAM, PAM, and NHI governance at the same time, which is where the category is heading.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why identity sprawl persists even where governance programmes exist.
A question worth separating out:
Q: Should organisations map AI agents to service-account style controls?
A: Yes, when the agent is acting on behalf of a business process rather than a person. Service-account style controls give teams a familiar way to manage scope, ownership, logging, and offboarding. The key is to add policy checks and audit at runtime, not only at provisioning.
👉 Read our full editorial: MCP can become an AI identity control plane for enterprise IAM
