> For the complete documentation index, see [llms.txt](https://docs.trustlogix.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trustlogix.io/trust-ai/mcp-gateway-and-ai-agent-setup.md).
# MCP Gateway and AI Agent Setup
This document provides a detailed, step-by-step walkthrough for configuring the TrustLogix MCP Gateway, setting up the TrustLogix AI Agent, and registering Snowflake MCP services within the TrustLogix platform.
***
## EntraID Configuration & TrustLogix Gateway Registration
The TrustLogix MCP Gateway is a centralized proxy deployed by TrustLogix that intercepts all calls to registered MCP servers. To function, this gateway uses a dedicated service principal to securely connect with the TrustLogix platform and downstream MCP servers, allowing it to fetch the authorized MCP server list, enforce active security policies, and act as a secured MCP client to the proxied customer MCP servers.
**1. Create the MCP Gateway Azure Application**
* Purpose: You must create a dedicated Azure application to manage authentication for the MCP Gateway.
* Set up the EntraID Application to configure the TrustLogix service principle for Gateway authentication and authorization. Follow the Azure documentation to create and configure the Azure application: [Azure App Registration](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app)
* Important Configuration: While setting up the application in the Azure portal, add the following redirect URL: example: https\://{dp.trustlogix.io}/api/mcp/oauth/callback\
Note: Adjust the domain name as provided by the TrustLogix team.
* Important Configuration: While setting up the application in the Azure portal, navigate to Expose an API tab and add the scope gateway\_access as a scope.\
When adding the gateway\_access scope, select user consent.\
The resultant scope should be api://{client\_id}/gateway\_access
**2. Register the MCP Gateway in TrustLogix**
* Access Console: Log in to the TrustLogix console and select MCP from the left-hand navigation menu.
* Enforcement Strategy: Click on Enforcement Option and select MCP Gateway.
* Enter Credentials: Input the Client ID, Client Secret, and Token/Authorization Endpoint generated from your Azure application into the Security Credentials (OAuth) section. For Azure, ensure that gateway is configured with v2 Azure endpoint
**Note**: Copy the Gateway URL provided in the screen, agent developers will use this in the agent code. They need to use this URL when instantiating the MCP Client
## Configuring AI Agent & Attribute-Based Access
To apply the correct security rules, TrustLogix needs to know exactly who is requesting data and which AI agent is acting on their behalf. By synchronizing rich identity metadata from Azure, we provide TrustLogix with the context required to enforce dynamic, Attribute-Based Access Control (ABAC) policies—ensuring that users and AI agents only access the data they are explicitly authorized to see.
**1. Define Attributes in TrustLogix**
Next, define how TrustLogix categorizes the data it receives from Azure.
1. Navigation: Go to the Attribute Management section in the left-hand menu.
2. Create Attributes: Click Add Attribute and define the Identity Type (select either User or Agent). Select TrustLogix as the target.
3. Sync Sources: Link these newly created attributes to your attribute source integration so TrustLogix can pull relevant metadata—such as Department, Azure Groups, City, or Purpose.
4. Create TrustLogix PIP user attributes using the attribute source integration (e.g., Department, Azure Groups).\
\
**Prerequisite**: If mapping user or agent attributes into any target from an external source like Azure, the TLX Control Plane itself requires a service principal for authorization to Azure when syncing attributes. To set this up, see the relevant [Attribute Source Connection Configuration Docs](https://docs.trustlogix.io/integrations/attribute-source-connection/azure-ad-or-ms-entra-graph-endpoint#id-3.-follow-the-prerequisite-steps)
**2. Create AI Agent Azure Application**
Purpose: You need a service principal Azure application that represents the AI agent identity that is used for authorization to the MCP gateway, and for client\_id unique identifier for agent attribute.
1. Follow the[ ](https://docs.trustlogix.io/integrations/attribute-source-connection/azure-ad-or-ms-entra-graph-endpoint#id-2.-configure-the-connection-details)[Azure App Registration](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) to create this application.
2. Redirect URL: For this application, navigate to the Authentication settings and set the redirect URL to: example:
Customers would put the callback for their AI agent clients.
3. Grant API Permission: For this application, navigate to the API permissions and select Add a permission. In the APIs my organization uses, search for the Gateway application that was created step 1. Select that application, then in Delegated permissions, select gateway\_access. After creating the API permission for the agent to access the Gateway, select Grant admin consent for Default Directory
**3. Create the AI Agent**
1. Navigation: Go to AI Agent in the left-hand menu and click Create AI Agent.
2. Identity: Provide a descriptive name (e.g., "Health Dev Agent"). Enter the Client ID, Client Secret, and Scope of api://{client\_id}/.default
3. Assign Attributes: After validating the credentials, Manually assign metadata to define the agent's persona for policy evaluation. For example:
1. Agent Purpose: Sales
2. Agent License: GLOBAL
## Registering MCP Services & Securing Tools
With the identity and attribute pipeline established, the final step is to bring your AI Agent online and connect it to your data environments. By registering the MCP service, TrustLogix automatically discovers the underlying tools it provides (such as specific Snowflake operations). This visibility allows you to create and deploy granular access policies, ensuring strict governance over exactly who—which users and AI personas—is authorized to execute specific tools.
\
**Prerequisites for registering Snowflake MCP service and deploying policies**
1\. **Snowflake Account Registration**
A snowflake account must be first registered with TrustLogix. See [Snowflake Account Registration Docs](https://docs.trustlogix.io/data-sources/snowflake). Ensure you also run the mcp\_grants SQL script. This script grants Control Plane the necessary privileges to discover MCP servers within snowflake as they are created across the whole account.
2\. **Snowflake JWT Service Principal Setup**
This auth option uses a static snowflake service principal via JWT. Refer to [Snowflake Key Pair OAuth for Custom Client Docs](https://docs.snowflake.com/en/user-guide/oauth-custom#using-key-pair-authentication). Make sure to save your private key and passphrase somewhere safe for later
3\. **Snowflake External OAuth (Azure) Service Principal OBO Setup**
This auth option sets up the TrustLogix proxy/gateway from step 1 as an external OAUTH azure client service principal in Snowflake. Please refer to [Snowflake External OAuth Integration](https://community.snowflake.com/s/article/Create-External-OAuth-Token-Using-Azure-AD-For-The-OAuth-Client-Itself).
This step also requires retrieving an OAUTH token yourself to use in the VERIFY\_EXTERNAL\_OAUTH\_TOKEN function. You can do this using services like Postman, Insomnia, etc. Ensure that for this request, it is of type Client Credentials. This is to retrieve a token that represents the service principal (the gateway) to tie it to a new user in Snowflake registration as part of Step 6. Use the gateway’s configured client id and secret, however for scope, ensure you request for ./default permission on the snowflake resource client id (i.e. api://{sf\_client\_id}/.default).
Here, you will register another azure application representing snowflake as a resource. Expose the scope session:role-any so that the default role of the the user you set up in step 6 create system user is used. If you configure another specific role instead to be used, the scope should be session:role:{ROLE}, as specified in step 1 register OAUTH app.
\
We then need to give the gateway access to this snowflake resource. Go to the gateway registered client app and navigate to the API permissions and select add permissions. Search for the snowflake resource, and add the exposed session scope. Then grant admin consent to provision the permission.
4\. **Data access grants**\
Ensure that the default role assigned to the underlying service principal in JWT, or in OBO the role specified in the scope, has access to the database, schema that the snowflake MCP resides in, as well as the MCP object itself, and any data that would possibly be queried by the gateway. Access controls will be enforced via the obo propagated logged in user conditions.
Finally, register the target service (e.g., Snowflake MCP) and enforce your security policies.
* **Registration**: Under MCP, click Register MCP Service.
* **Server Configuration**: Enter the Server Name and select Snowflake as the type
**Authentication Options**
1. Authentication Strategy: identity the MCP Gateway will use when connecting to your MCP service.
1. JWT: Service account will be accessing the MCP server
2. Oauth: Oauth based authentication for downstream applications
2. Service Identity (Oauth): identity the MCP gateway will use when connecting to the MCP server
1. Gateway: Reuse the gateway credentials to connect to the MCP server
2. Custom: Provide your own credentials. This involves providing a client id and secret
3. Grant Type (Oauth)
1. Client Credentials
2. Token Exchange: Exchange tokens on behalf of the user
4. Type of Exchange (Token Exchange):
1. Delegation (OBO): Use the service identity selected above to authenticate on behalf of the user
2. Impersonation: Act as the user identity
* **Tool Discovery**: TrustLogix will automatically scan the Snowflake MCP to discover available tools, such as sql\_exec\_tool.
**Deploy Security Policies**
* Server Access Policy: Define who can access the entire MCP server based on attributes (e.g., Purpose Equals Sales).
* Tool-Level Policy: Create specific rules for individual tools (e.g., allow sql\_exec\_tool only if Department Equals Finance OR Purpose Equals Sales).
* Deployment: Review the summary (showing default behavior as Deny by default) and click Deploy Policies to activate protection.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.trustlogix.io/trust-ai/mcp-gateway-and-ai-agent-setup.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.