---
title: "Case Study: Self-Serve Data Agents Without Leaking Credentials — onemcp"
description: "An illustrative data team wanted analysts to use AI agents against production systems without handing out database and warehouse credentials. onemcp's host-side auth kept the secrets off every laptop."
ogTitle: "Case study: self-serve data agents, secrets stay put"
ogDescription: "How a data team gave analysts AI agents over production tools while keeping every credential host-side in a onemcp portal."
url: "https://onemcp.dev/case-studies/data-team-secure-agents"
eyebrow: "Case study · Data & governance"
headline: "Give analysts agents over production data — without handing out the keys."
summary: "A data team wanted self-serve AI agents against the warehouse and internal APIs, but not a world where every analyst's laptop held production credentials. A onemcp portal kept auth host-side and access central."
industry: "Data & analytics"
teamSize: "~25 analysts + a 4-person data platform team"
stack: "Snowflake · dbt · Postgres · internal metrics API · GitHub"
illustrative: "Illustrative scenario based on common onemcp deployments. The team is a composite, not a named customer, and the figures are representative rather than measured."
results:
  - "0 production credentials on analyst machines"
  - "1 portal as the central access-control point"
  - "New tools added centrally, not laptop by laptop"
quote: "The unlock wasn't the agent — it was that we could say yes to it. Access lives in the portal, so security had one thing to review instead of thirty laptops."
quoteAttribution: "Data platform lead (illustrative)"
---

## Background

A data team of around twenty-five analysts wanted to use AI agents for the daily grind: writing queries, chasing down metric definitions, checking pipeline health. The tools they needed — Snowflake, dbt, an internal metrics API, a couple of Postgres replicas — all had MCP servers available.

The blocker was never the agent. It was the question security asked every time: *where do the credentials live?*

## The challenge

The obvious path was to give each analyst the MCP servers and let them authenticate. Security wouldn't sign off, and they were right not to.

- **Credentials would spread.** Two dozen analysts each holding warehouse and API credentials on personal machines is two dozen places a secret can leak, and no clean way to rotate.
- **Access was all-or-nothing.** Handing over a server meant handing over whatever that server's token could do, with little visibility into who had what.
- **Governance didn't scale.** Reviewing and revoking access laptop by laptop was not a process anyone wanted to own.

## The approach

The data platform team ran a single onemcp **portal** as the boundary between analysts and production systems.

- **Credentials stay host-side.** Each upstream is authenticated once, in the portal. Native upstream OAuth and tokens live there — never on an analyst's machine, never in a repo. Analysts' agents connect to the portal, not to the databases.
- **Access is central.** Which servers are available, and to whom, is decided in one place. Onboarding a new tool is a portal change; revoking access doesn't require touching anyone's setup.
- **The catalog stays lean in context.** Through Code Mode, the portal exposes `search`, `describe`, and `execute` instead of every tool's schema — so agents pull only the tools a task needs, and the analyst's context stays on the analysis.

## Results

- **No production credentials on laptops.** Secrets live in the portal. A departing analyst or a lost machine is no longer a credential-rotation emergency.
- **One place to govern.** Security reviews and manages access at the portal, not across twenty-five individual configs.
- **Self-serve without the sprawl.** Analysts got their agents; the platform team kept a single, auditable control point — and adding the next tool is one central change.

> The unlock wasn't the agent — it was that we could say yes to it. Access lives in the portal, so security had one thing to review instead of thirty laptops.

## Related case studies

- [A platform team puts 20 MCP servers behind one endpoint](/case-studies/platform-team-mcp-gateway)
- [An AI support agent on a token diet](/case-studies/support-agent-token-diet)