The fastest way to give an agent access to your business data is also the fastest way to lose control of it. Point an MCP server at a production Salesforce instance, hand it a service account with broad read access, drop the key in an environment variable, and within a few days you have an internal “account intelligence” agent that answers natural-language questions about any customer. The demo is clean: three at-risk accounts surfaced, recent tickets summarized, next steps suggested. Leadership is impressed.
Then a success manager asks a slightly broader question. The model requests additional fields. The server returns them. Sensitive contract notes and internal comments that should never have left the CRM land in a shared channel. No one intended harm. The infrastructure simply had no real boundary between “helpful agent” and “over-privileged principal.” That's not a hypothetical. It's a near-miss a PM named Elena lived through, and her takeaway is the thesis of this chapter.
We thought speed meant connecting everything. Speed actually meant deciding what the agent was allowed to know.
Elena, after the near-missMost PMs still treat MCP as a convenient way to give agents tools. In 2026 that view is already behind the curve. MCP has become the primary data and API layer for agents. The protocol itself is now mature: stateless core, hardened OAuth, enterprise-managed connectors. The hard product work is everything around it: identity, least privilege, auditability, and deciding what an agent is actually allowed to see and do.
What AI Infrastructure Really Means Now
The model is the tip. The real surface is the layer that makes business systems (CRM, product events, billing, support, internal knowledge) discoverable and actionable by agents without turning those systems into open attack surfaces.
By mid-2026 MCP had crossed from interesting protocol to default connective tissue. Anthropic donated it to the Linux Foundation's Agentic AI Foundation. OpenAI, Google, Microsoft, Salesforce, AWS, Stripe, Notion, Slack, Atlassian, and dozens of others ship official servers. SDK downloads run into the hundreds of millions per month. Enterprises are no longer debating whether to use it. They're dealing with the governance and security consequences of teams spinning up servers faster than policy can keep up.
Santiago (@svpino) has been blunt about the current state of most implementations:
“Most MCP implementations rely on exposing static API keys and giving agents over-privileged access… Nobody is doing session management or fine-grained permissions. Nobody knows what agents accessed what data because there's no visibility.”Santiago @svpino
That pattern is still common. And it's exactly the pattern that turns a useful agent into a new class of risk.
MCP as a Trust Boundary, Not Just a Connector
Every MCP server is a new principal. When you expose a Salesforce or product-usage server, you're creating an identity that can read (and sometimes write) sensitive data. That identity needs the same rigor you'd apply to a new service account, only more so, because the “user” is non-deterministic.
Jason Fleagle, Head of AI, put the operational reality cleanly:
“MCP provides a common connection layer, but structural governance still has to be operated. Teams need server identity, scoped capabilities, approval for sensitive calls, version pinning, evidence per action, revocation, and an exit path when a server or tool becomes unsafe.”Jason Fleagle, Head of AI
The mature pattern in 2026 looks like this:
▸ Distinct identity for each agent or agent class, not a shared service account.
▸ Short-lived, scoped credentials issued through OAuth 2.1 / OIDC with the company IdP.
▸ Tools designed around outcomes rather than raw endpoints.
▸ Full audit trail: which agent identity, which tool, which resources, when.
▸ Read vs write, staging vs production cleanly separated.
▸ A catalog and approval process so shadow MCP doesn't proliferate.
Daniel (@MnFounder) summarized the safety principle: “Agent safety is not a prompt setting… An agent is only useful when its permissions and tool access fail safely.”
Making Business Data Actionable Without Opening the Floodgates
The goal is never “give the agent the CRM.” It's “give the agent the specific answers and actions that create value while keeping the underlying systems protected.”
Design tools for agent goals, not API parity
get_opportunity_by_id
list_contacts_for_account
get_usage_events
Agent stitches three low-level calls and invents the business logic.
get_customer_health_summary(account_id)
One call. Business logic encoded once, in the tool.
The practical rules that hold up: never point an agent at the production database or full CRM API with broad credentials. Use a dedicated, narrowly scoped data product or service role. Start with a tiny surface of three to five high-value tools, since every additional tool increases both utility and risk. Enforce least privilege at two layers: the MCP server and the underlying system. And log everything: if you can't answer “which agent accessed which customer record last Tuesday?” you don't have governance.
Real Stories from the Trenches
Elena's rebuild. The Salesforce leak from the opening had a second act. Elena's team tore the original server down and rebuilt with three outcome-oriented tools only, forced OAuth through their identity provider, added request-level logging, and put a human approval gate on any tool that could surface contract values. Adoption actually increased. People trusted the answers more once they knew the boundaries were real.
Marcus and the product-usage server. Marcus, growth PM at a usage-based SaaS company, needed an agent that could answer questions about feature adoption and retention drivers. He refused direct warehouse access. Instead the team built a thin MCP server backed by pre-aggregated, privacy-reviewed datasets. The agent could never run arbitrary queries. Rate limits and row-level filters were enforced at the server. Six months later the same server was consumed by three agents and two internal tools. “Once we stopped trying to give the agent 'all the data,' the answers got more reliable and the security conversation got quieter.”
Rafael and the shadow MCP cleanup. At a larger organization, Rafael's platform team discovered more than a dozen internal MCP servers individual squads had stood up without review. Most used static keys. Two could write to production. The cleanup required a central catalog, an approval workflow, version pinning, and a gateway. A full quarter of work. “Once MCP becomes easy, shadow infrastructure appears faster than governance. The cost of cleaning it up is always higher than putting a lightweight process in place early.”
Framework: MCP Server Decision Canvas
Answer these before any internal server is built or connected. Fuzzy on 4 to 7? The server isn't ready.
- 1
Business outcome this enables that we can't get another way?
- 2
Minimum set of tools (start with ≤5) the agent actually needs?
- 3
Absolute minimum data the agent must see?
- 4
Agent identity: how is it authenticated and authorized?
- 5
Credentials: how short-lived and narrowly scoped?
- 6
Audit trail: what exists, and who can query it?
- 7
Blast radius if the server or agent is compromised or prompt-injected?
- 8
Build vs vendor? Build only when data is proprietary, workflow domain-specific, or compliance requires code ownership.
Common Mistakes
| Mistake | Fix |
|---|---|
| MCP as a thin wrapper around REST APIs. | Design for agent goals, not endpoint parity. Encode business logic in the tool. |
| Static keys and shared service accounts. | Distinct identities, short-lived scoped credentials. One compromise ≠ full breach. |
| No independent audit trail. | If you can't answer “which agent touched which record Tuesday?” you have no governance. |
| Every team spins up its own servers. | Central catalog + review. Shadow MCP is the new shadow IT. |
| Prod access “just for a prototype.” | Prototypes become production. Start with the security posture you'll need. |
Key Takeaways
MCP is no longer a developer curiosity. It's the primary way agents reach business data. Treat it as infrastructure.
The highest-leverage work is designing tools and the trust boundary, not wiring the protocol.
Agents need their own identities, short-lived scoped credentials, and full auditability. Human IAM patterns aren't enough.
Start narrow: few outcome-oriented tools, tight data access, strong logging. Expand only with evidence.
Force the “what is the agent allowed to do?” conversation before the first server deploys. Tightening later costs far more.
Ask Your Platform / Security / Data Team
1. “For every MCP server that can touch customer or financial data, can we show the exact identity, scopes, and last 30 days of audit logs for any given agent?”
2. “What's our current process for approving a new internal MCP server, and who owns the catalog and versioning?”
3. “If we had to revoke all agent access to Salesforce or the product events store in the next hour, how many places would we touch and how long would it take?”
the flashiest demos. They'll be the ones that made
business data safely actionable and kept the trust
boundary intact as agents and servers multiplied.
That's product and infrastructure work. Own it early.
AT A GLANCE
| Core concept | Every MCP server is a trust boundary, not just an integration |
| Frameworks | The Agent Data Stack, MCP Trust Boundary, 8-point Decision Canvas |
| Stories | Elena (broad key leak), Marcus (constraint as feature), Rafael (shadow MCP cleanup) |
| Key rule | Distinct identity, scoped short-lived creds, audit everything. Start narrow. |