In Parts 1 and 2 of this series, we explored Obot’s architecture and walked through deploying MCP servers. This third blog post covers the security aspects of deploying the Obot MCP gateway. To ensure a scalable and secure solution, the gateway must effectively control who can access which MCP servers, manage credentials, and provide an ability to audit all interactions. Comprehensive auditing is critical for IT compliance and risk mitigation, and it also helps developers debug any issues that may arise.
This tutorial is part of the Building Secure AI Infrastructure with the Obot MCP Gateway series. Check out the other parts below:
MCP servers allow one to extend the capabilities of AI agents by allowing them to connect to enterprise systems. These include CRMs, databases, cloud platforms, and internal tools. The main challenges that need to be tackled from a security perspective when deploying MCP Servers are:
Prevent Unauthorized Access: Without proper RBAC Controls, any user with a connection URL to MCP could access sensitive systems
Credential Sprawl: API keys and tokens scattered across individual users laptops, unencrypted config files, and environment variables
Audit Gaps: Lack of visibility into what agents are doing or which data they are accessing
Compliance Risk: Regulations like HIPAA, PCI DSS, and GDPR require detailed logging and access controls
To address these challenges, Obot MCP Gateway uses a layered security model to address the required capabilities such as centralized authentication, role-based access control, secure proxying, and comprehensive audit logging.
Try Obot Today
⬇️ Download the Obot open-source gateway on GitHub and begin integrating your systems with a secure, extensible MCP foundation.
Identity and Authentication
Obot integrates with enterprise identity providers(IDP) to authenticate users before they can access any MCP resources. This ensures that only authenticated users can discover and connect to approved MCP servers. User onboarding and offboarding becomes seamless when integrating with these IDP systems thereby lessening the burden on the IT.
Supported Identity Providers
Obot supports the following authentication providers:
GitHub: OAuth authentication for developer teams
Google: Google Workspace integration for organizations
Okta: Enterprise SSO (Obot Enterprise edition)
Microsoft Entra: Azure AD integration (Obot Enterprise edition)
Authentication Flow
When a user attempts to access Obot, the following authentication flow occurs:
User navigates to the Obot UI interface or attempts to connect via an MCP client
Obot redirects to the configured identity provider for authentication
User authenticates with their corporate credentials
Identity provider returns user identity and group memberships
Obot maps user to appropriate role and permissions
User sees only the MCP servers they are authorized to access
Role-Based Access Control (RBAC)
Integrating with IDP systems ensures that the users are authenticated. We still need a way to control what functionality is available to the authenticated users. Obot uses role-based access control to manage what users can do within the platform. Each role has different permissions and sees different parts of the interface.
User Roles
Role
Description
Key Capabilities
Owner
Full platform management plus role assignment
All Admin capabilities plus assigning Owner and Auditor roles
Admin
Full platform management except assigning Owner or Auditor roles.
MCP Management, Chat Management, User Management, App Preferences
Power User+
Extended power user with sharing capabilities
Create MCP Registries and share MCP servers with other users
Power User
Self-serve MCP server publishing
Publish custom MCP servers (personal use), view personal audit logs
Basic User
Standard end-user access
Connect to MCP servers, use Obot Chat, create projects
Auditor
Add-on role for sensitive data access
Read-only access to MCP request/response bodies, chat threads, task runs
Note: The Auditor role can be combined with any other role. In order to view request/response or other sensitive information, you need to explicitly assign an Auditor role otherwise only Metadata associated with the sensitive information is visible.
MCP Registries for Access Control
MCP Registries provide fine-grained control over which MCP servers are visible to which users. Administrators can create custom registries that map server entries to specific users and groups.
Navigate to MCP Management > MCP Registries
Create a new registry (e.g., “Engineering Team”, “Finance Department”)
Assign users or groups from your identity provider to the registry
Add the MCP servers that should be visible to this registry
By default, Obot includes an “everyone” group. For tighter security, remove this group and assign specific teams to specific registries, ensuring users only see MCP servers they are authorized to use.
The MCP Proxy Layer
All MCP traffic in Obot flows through a secure proxy layer. This architectural decision provides centralized policy enforcement, credential management, and audit logging regardless of whether the MCP server is hosted by Obot or provided by a third party.
How the Proxy Works
The MCP Proxy is both an MCP server (for clients to connect to) and an MCP client (which connects to the actual MCP server). This design provides:
Policy Enforcement: Every request is validated against access control rules before forwarding
User Isolation: Credentials and sessions are separated per user to prevent cross-contamination
Request Filtering: Administrators can define guardrails to inspect and reject malicious or unauthorized requests
Complete Logging: Every tool call, prompt, and response is captured for audit purposes
Credential Management
Obot supports encrypting sensitive data at rest in the database using industry-standard encryption providers. The external KMS integration for managing cryptographic keys separately from Obot’s database, significantly enhances the security and compliance by separating data storage and key management.
Obot’s Encryption covers all critical information handled by Obot which include the following:
User Data: Personal information and configuration settings.
Credentials: Stored passwords, API keys, and secret access tokens.
OAuth Tokens: Access and refresh tokens for third-party services.
Session Details: Session IDs and metadata to prevent hijacking.
Audit Logging
Obot provides comprehensive audit logging to meet compliance requirements and support security investigations. Every MCP interaction is recorded with detailed metadata.
What Gets Logged
User Actions: Who accessed which MCP server and when
Tool Calls: Every tool invocation with parameters
Request/Response Bodies: Full content (visible only to Auditor role)
Viewing Audit Logs
Access to audit logs depends on your role:
Power Users: Can view logs only for servers they deployed
Admins/Owners: Can view metadata for all activity (not request/response bodies)
Auditors: Can view complete logs including sensitive request/response content
Exporting Audit Logs
Admins and auditors can export audit logs directly from the UI for compliance reporting, archival, or integration with external SIEM systems.
Summary
In this guide, we explored Obot’s comprehensive security model for MCP infrastructure. Key takeaways:
Integration with identity providers (Okta, Entra, Google, GitHub) for authenticating users before MCP access
Predefined RBAC roles (Owner, Admin, Power User+, Power User, Basic User, Auditor) provide granular access control
Custom MCP Registries that map MCP servers to specific users and groups
The MCP Proxy enforces policy, isolates users, and logs all interactions
Sensitive information is encrypted by integrating with external KMS systems.
Comprehensive audit logging supports compliance and security investigations
In Part 4, we will cover hosting, observability, and the developer experience: how to run MCP servers on Kubernetes, monitor usage and health, and build a self-service MCP catalog for your organization.
