On this page
MCP security is the set of controls that decide what an AI agent may read and do when it connects to your systems through the Model Context Protocol. There are five that matter: scoped authentication, so the agent acts as a known identity; role-based access, so it sees what that identity is allowed to see; PII and data policy, so restricted fields stay restricted; tool governance, so it can only call approved tools and only write where approved; and an audit ledger, so every read, call and write is recorded and reversible. They belong in the MCP server, enforced once for every agent, rather than in each agent's prompt where they will be forgotten.
We are writing this because the security questionnaire has become the critical path and we would like to answer them.
The questionnaire
A growth marketing leader at a compliance software company told us his IT team sent about twenty questions before our MCP connector could be switched on. "Our IT team is being very thorough. It slows me down." A performance marketing leader at a B2B commerce software company put it with less patience: "your tech team takes two years to approve anything." A marketing operations team at a healthcare IT company found that a read-only CRM user for an outside system would, under their SSO rules, require issuing us a company laptop and an internal email address.
None of those IT teams is wrong. Two years ago the hard part of a GTM AI project was the model. The model is now a commodity and the hard part is the connection, because an agent that can read the CRM, the marketing automation platform and the warehouse, and write back to all three, is a new kind of user with a new attack surface. The question is not whether to control it. It is whether the controls live in one reviewable place or get scattered across every agent and every source-system connector.
Gartner's May 2026 note on agent governance predicts 40% of enterprises will demote or decommission autonomous agents by 2027 because governance did not keep up, and blames the habit of treating governance as binary: locked down or fully trusted. The analysts name the baseline controls, scoped data access, user authentication, usage logging, basic security testing, and add output testing and real human review as agents move from observing to acting. Every one of those is a property of the connection layer. For most GTM teams this year, the connection layer is MCP.
The five controls
Scoped authentication
Every call runs as a named identity, either the person driving the assistant or a service identity with an explicit scope. There is no anonymous agent. Tokens are short-lived and bound to a workspace, so a connector someone pasted into a team channel cannot be lifted and reused. This is page one of the questionnaire.
Role-based access
The agent inherits the permissions of whoever it is acting as. A rep asking "which of my accounts are at risk" gets their accounts. A CMO asking "which campaigns should we defund" gets the attribution view. Neither sees the other's data, and neither sees anything the same person could not already see logged in. The point of doing this at the MCP layer is that the rule is written once and holds for every agent, every assistant, every custom app. Write it per agent and it drifts within a quarter.
PII and data policy
Restricted fields (personal email, phone, whatever your data protection policy classifies) are masked or withheld at the gateway, whatever the agent asked for. Regional rules live here too: an agent working for an EU team sees what EU policy allows. We ship a restricted-PII configuration for enterprise assistants for exactly this reason; the setup notes cover it.
Tool governance
An MCP server exposes tools. Governance decides which tools exist, which identities can call each one, and, for the tools that write (update an opportunity, push an audience, trigger a sequence, move spend), whether the call runs immediately or waits for approval. This maps almost exactly onto Gartner's four autonomy levels. Read tools are observe. Prediction and recommendation tools are advise. Write tools with approval are act-with-approval. Fully autonomous writes are the fourth level, and a governed gateway is what lets an enterprise decide, tool by tool, which level it has actually signed up for. On the GTM Harness that decision is the Propose, Approve, Commit, Roll back sequence.
The audit ledger
Every read, every tool call, every write, recorded with identity, time, inputs and result, in a record the agent cannot touch. Two things hang off it. Security can answer "what did the agent do last Tuesday" without reconstructing it from six systems' logs. And RevOps can roll back an action that should not have happened, because the ledger knows the prior state. Gartner's March 2026 predictions expect half of all AI agent deployment failures by 2030 to come from insufficient runtime enforcement by governance platforms. A ledger plus tool governance is runtime enforcement. A policy document is a policy document.
One gateway or a dozen servers
The alternative is a separate MCP server per source system: one for the CRM, one for marketing automation, one for the warehouse, one for the call recorder. Each with its own credential, its own permission model, its own log, its own security review. And the agent, having pulled raw records from all of them, is left to work out how they relate. A marketing leader at a threat intelligence company located the real risk in that setup: "we don't want everyone going rogue, saying I'm influencing 100 billion of pipeline." An agent reasoning over unreconciled records produces confident, ungoverned numbers, and it produces them fast.
A single governed gateway applies the five controls once. That is how we built the Unified MCP layer. CRM, marketing automation, ad platforms, email and calendar, conversations, product usage and the warehouse come in. Authentication, RBAC, policy, the ledger and tool governance sit in the middle. Assistants, copilots, our own agents, customer-built agents and workflow tools call one endpoint. The security review happens once. Revocation happens once. And because the gateway serves resolved, harmonised context rather than raw records, the agent reasons over one version of each account instead of four.
What to ask any vendor, including us
Does the agent act as a named identity, and can its scope be limited? Are permissions inherited from the operator, and where exactly is that enforced? Which fields are masked by default, and can policy vary by region or role? Which tools can write, and is approval a configuration screen or a promise in a slide? Is there a ledger, can the agent alter it, and can an action be rolled back from it? How many connectors will security be asked to review, and how many credentials will exist after go-live?
The vendor who answers those with settings rather than sentences is the one whose questionnaire comes back approved.
Frequently asked questions
What is MCP security?
The controls that decide what an AI agent can read and do when it connects to enterprise systems over the Model Context Protocol: who it acts as, what data it can see, which tools it can call, what it may write, and the record of everything it did. They are enforced at the MCP server, not in the model's prompt.
Why does an MCP server need role-based access control?
Because the agent inherits the permissions of whoever is driving it, and different people are entitled to different data. A rep should see their accounts. A CFO should see the forecast. Neither should see restricted personal data unless policy says so. RBAC at the MCP layer writes that rule once for every agent instead of trusting each one to behave.
What is an audit ledger for AI agents?
A record the agent cannot edit of every read, tool call and write, with the identity it acted under, the time, the inputs and the result. It lets security answer "what did the agent do" after the fact and lets RevOps roll back an action that should not have happened.
Is one MCP gateway safer than many MCP servers?
Usually. Every source-system server is its own credential, permission model and log. One governed gateway between enterprise systems and every agent applies authentication, RBAC, PII policy and logging in one place, which is easier to review, audit and revoke.
How does RevSure secure its MCP server?
The RevSure Unified MCP layer enforces scoped authentication, role-based access, PII and policy controls, tool governance and an audit ledger between enterprise systems and any agent or application, so every read, prediction and action runs through one governed endpoint. A restricted-PII configuration is available for enterprise assistants.
Related reading: AI agent governance, what is an MCP server, MCP for GTM.