Case study · Data & governance

Give analysts agents over production data — without handing out the keys.

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
Team
~25 analysts + a 4-person data platform team
Stack
Snowflake · dbt · Postgres · internal metrics API · GitHub

# At a glance

  • 0 production credentials on analyst machines
  • 1 portal as the central access-control point
  • New tools added centrally, not laptop by laptop

Illustrative scenario based on common onemcp deployments. The team is a composite, not a named customer, and the figures are representative rather than measured.

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

</> Read as Markdown

Stop wiring up servers. Start shipping agents.