Notifications
Clear all
Topic starter
19/08/2026 3:59 pm
TL;DR: MCP does not define authentication, role-based access control, or audit logging, so governance depends on the platform layer, according to Stacklok’s 2026 comparison of MCP platforms. The practical issue is not tool discovery, but whether identity attribution, least-privilege tool exposure, and structured logs can be enforced across shared environments.
NHIMG editorial — based on content published by Stacklok: Best MCP Platforms for Teams That Need Access Control and Audit Logs 2026
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 in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
Q: Why do MCP deployments create governance risk when access is only controlled at the server level?
A: Because server-level controls answer only whether a caller can reach the server, not what actions they can perform inside it.
Q: What do security teams get wrong about MCP audit logs?
A: They often treat logging as a dashboard problem instead of an evidence problem.
Practitioner guidance
- Demand per-request identity attribution Require each tool invocation to carry a verified user or agent identity, not a shared service account key.
- Validate tool-level RBAC before deployment Test whether the platform can permit read operations while denying write and export actions within the same MCP server.
- Insist on structured SIEM-ready logs Confirm that audit output includes identity, tool name, parameters, timestamps, and response data in a format your SIEM can ingest without a custom integration layer.
What's in the full article
Stacklok's full comparison covers the operational detail this post intentionally leaves for the source:
- Architecture notes on how the embedded authorization server runs in-process inside the cluster
- Product-by-product comparison of audit log models, identity options, and deployment boundaries
- Implementation details for Kubernetes RBAC auto-provisioning and vMCP policy enforcement
- Platform limitations and fit guidance for teams that need open-source licensing or air-gapped deployment
👉 Read Stacklok's comparison of MCP platforms for access control and audit logs →
MCP access control and audit logs: which platforms actually govern tools?
Explore further
19/08/2026 4:36 pm
MCP governance fails when teams confuse protocol standardisation with access control. The MCP specification solves discovery and invocation, but it does not solve identity attribution, authorisation, or audit quality. That gap forces practitioners to treat the platform layer as the real control plane for NHI governance. The implication is that MCP rollout without platform enforcement is not a protocol decision, but a governance decision.
A few things that frame the scale:
- Only 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, according to AI Agents: The New Attack Surface report.
- 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.
A question worth separating out:
Q: What is the difference between tool-level RBAC and namespace isolation in MCP platforms?
A: Tool-level RBAC limits which functions a caller can invoke, while namespace isolation limits where those functions can operate inside shared infrastructure. Both matter, but they solve different problems. Tool-level RBAC reduces action scope, and namespace isolation prevents cross-team exposure in multi-tenant deployments.
👉 Read our full editorial: Best MCP platforms for access control and audit logging in 2026
