Data Gateway Use Cases: Direct MCP from AI to SaaS

AI agents already have access to Salesforce, Snowflake, and most of the other SaaS systems IT is responsible for, and in most cases nobody had to approve it. This is the first of six scenarios walking through how that happens in practice: how it gets set up, why it works, why it's a blind spot for IT, and how a data gateway closes it without shutting the access down.

Direct MCP is the simplest version of this, and the one already live in the most accounts. An AI agent connects straight to a SaaS system using access IT already provisioned somewhere else, with no gateway and no additional layer in between. It's also the version most IT teams don't yet know is happening.

An account executive with a Claude Enterprise seat can get access to the Salesforce connector if it has been provisioned by IT. The AE opens settings, clicks connect, and completes a standard OAuth consent screen in Salesforce. Claude now holds a refresh token scoped to that AE's Salesforce profile. Setup takes about ninety seconds.

From that point the AE asks questions in plain language, and Claude issues API calls against Salesforce as that AE.

It works because the OAuth token cannot exceed the AE's own Salesforce profile and permission sets. If the AE cannot see a record in the UI, the agent cannot see it through the API, so least privilege is implemented by default.

It also works because IT already made two decisions that enable it - they bought an enterprise AI license and granted API / MCP (Model Context Protocol) access to Salesforce. The AE simply combined two approved tools, so there is no shadow IT here in the usual sense. That’s what makes it spread quickly.

1. You can no longer forecast API consumption

Salesforce Enterprise Edition allocates 100,000 API calls per 24 hours, plus 1,000 per Salesforce or Platform license. A 500 seat org gets 600,000 calls per day with concurrency caps for long-running requests.

An agent does not know your Salesforce schema by default, so it describes objects, samples records, retries failed queries, and re-reads the context it already fetched. One conversational question can become dozens of calls. Ten AEs exploring their pipeline can generate more traffic than your integration layer, exceeding the rolling API and concurrency limits, blocking all API requests from your marketing automation tools and data warehouse sync.

2. You have no visibility into what leaves Salesforce

Every result set the agent retrieves passes into the model provider's context including customer names, contact details, deal terms, support history, whatever the query returned. IT has no record of which fields moved and no ability to mask sensitive PII data.

The common reassurance is the Zero Data Retention (ZDR) clause in the enterprise agreement. Based on recent experience, it’s best to treat that as a variable. Anthropic changed its policy in June 2026 so prompts and outputs for covered models are now retained for 30 days on every platform where those models are offered. This change was made to detect attacks that span multiple requests. Architect your systems on the assumption that raw data you send to an AI may sit somewhere that you have no visibility or control over.

3. No usable audit trail, and no reuse

Salesforce logs the API calls and the Connected App. It cannot tell you whether the AE typed a request or the agent decided on its own to fetch more context.

However, Salesforce does not record the original question (prompt). You can reconstruct which records were read. You cannot reconstruct why, what the agent concluded, or what the AE did with the answer. For an access review or incident, that information is relevant.

The query the agent composed is discarded when the session ends. Ask the same question again and it gets rebuilt from scratch, possibly differently, possibly returning a different answer. There is no artifact to approve, tune, or point at during a subsequent data audit, which can be a significant issue in regulated industries.

The gateway changes where the work happens. Claude connects to MarcoPolo over MCP as the AE, and MarcoPolo holds the Salesforce credential in a privileged mode that the model cannot reach.

Query results land in a persistent workspace with a data caching layer and a python coding environment. The agent can write code to filter, join and aggregate data there and only the answer needs to enter the model context, not the raw rows. Queries and results persist across sessions, so a repeat question reuses a stored query instead of re-describing the schema and re-hitting the API, which addresses the first. And because every query, result and script is recorded in the workspace and shipped to your SIEM, you get the audit artifact that Salesforce logs alone cannot produce.

Direct MCP is the version of this that's easiest to miss, because nothing about it looks wrong from where the AE sits. The access already existed, the results were already useful, and nobody had a reason to ask who was keeping track. The next scenario keeps the same AE and the same agent, and adds a second system underneath, a data warehouse the business already trusts, where the same question can return two different answers depending on which system agrees to ask.

If this sounds like what's already happening in your own stack, I'd like to see it. Book time with me and we'll walk through what a data gateway would actually look like on your systems.