Topic starter
20/08/2026 5:38 pm
TL;DR: Identity, exposure and evidence have to be governed together in an MCP gateway, according to Obot. Discovery, secrets and logging need one enforcement layer if access is going to stay reviewable at scale.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “Access Control, Security, & Proxying in Obot”.
Key questions
Q: Why do MCP gateways need both RBAC and audit logging?
A: RBAC decides what an authenticated user can do, while audit logging proves what happened after that decision.
Q: What are the signs that MCP credential handling is too exposed?
A: The warning signs are API keys, tokens and session details stored in config files, on laptops or in shared environment variables, especially when key management is not separated from data storage.
Q: Where does MCP security fail when access is open by default?
A: It fails when any user with a connection path can discover and reach servers without explicit entitlement mapping.
Practitioner guidance
- Define gateway-enforced access policy Map each MCP server to explicit user and group entitlements before allowing discovery or connection, and remove any broad default visibility paths that exceed business need.
- Separate visibility from execution rights Use RBAC so authenticated users only see the servers and functions they are meant to use, while reserving sensitive request and response access for an explicitly assigned Auditor role.
- Route all MCP traffic through one proxy path Force client-to-server interactions through a single proxy layer so policy checks, user isolation and request filtering are consistently applied before any tool call reaches a server.
Bottom line: MCP gateway security is really about controlling identity, exposure and evidence in one place rather than treating them as separate implementation tasks.
Glossary terms: MCP Gateway, Role-Based Access Control, Audit Logging, Credential Separation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
20/08/2026 6:23 pm
MCP governance fails when identity is treated as a front-door problem instead of a runtime control plane. A gateway that authenticates users but does not govern server visibility, request forwarding and audit capture still leaves material exposure. The article correctly places all three functions together because MCP traffic touches enterprise systems, not just chat interfaces. The practitioner takeaway is that MCP access policy has to travel with the request path.
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.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should organisations centralise MCP access through a proxy layer?
A: Yes, when multiple clients or third-party servers are in scope. A proxy gives security teams one place to enforce policy, isolate user sessions and capture activity for review. It is most valuable when the same MCP environment must support access control, secret handling and auditability without fragmenting those duties across servers.
👉 Read our full editorial: MCP gateway access and audit controls need one enforcement layer
This post was modified 2 days ago by NHI Mgmt Group