MCP governance, defined
What is MCP governance?
MCP governance is the set of controls that decide which people and agents may reach which tools through the Model Context Protocol, on what terms, with whose approval, and with what record. MCP itself authenticates a client to a server. Governance is everything that decision leaves open.
What the protocol leaves open
MCP connects an agent to a tool. It does not decide.
The standard is deliberately small. It says how a tool is described and how a client authenticates to a server. Three things an enterprise needs are outside it.
The person behind the client
MCP authenticates a client to a server. It does not know that the client is being driven by a specific employee, in a specific group, with a specific entitlement. Governance carries that identity onto every call.
The arguments of the call
A server exposes a tool such as update_opportunity. Whether this person may call it on this record with this amount is not the protocol’s question. Governance evaluates the actual arguments before the call is made.
The record
A server may log what it received. It cannot say who asked, through which assistant, what policy decided, or who approved. Governance writes that record once, in one place, for every server.
The controls
Six decisions, in the order a call meets them.
This is the route every call takes through a governance layer, whichever assistant it came from and whichever server it is going to. The homepage shows it moving.
1. Identity
The call is resolved to a person or a registered agent, using the groups your identity provider already maintains. Nothing is shared, pasted or installed to make that true.
2. Entitlement
Only the tools and Skills that person’s groups entitle them to exist for them. A tool outside their entitlement is not denied; it is not there.
3. Scan
The arguments are checked for secrets, personal data and injected instructions before any policy runs, so nobody is asked to approve a call a scan would then refuse.
4. Policy
Rules evaluated on the actual arguments: allow, hold for a named person, or block. A deal above a threshold waits for the manager. A query on personal-data columns is refused.
5. Credential
Only once policy allows is a credential brokered from your vault for that one call. The person never holds it and the client never sees it.
6. Record and cost
After the call lands, the record is written: who, which agent, which client, which tool, what was decided, who approved. The cost is attributed to the team. A blocked call is recorded too.
What MCP governance is not
Three things it gets confused with, and where each one stops.
An MCP gateway
A gateway proxies traffic to some servers and can authenticate, rate-limit and log it. Governance includes that and adds the part a proxy cannot know: which person is behind the client, what their groups entitle them to, and whether this call, with these arguments, should happen at all.
Agent security monitoring
Detection tells you what happened. It is valuable, and it is a different job. Governance decides what is allowed before the call is made and holds the consequential ones for a person. Run both if you like; do not mistake one for the other.
The identity provider
Your identity provider says who someone is and which groups they are in. It does not know what an MCP tool is, let alone whether an argument to it is acceptable. Governance consumes those groups as the source of entitlement and does the rest.
Where to start
Four steps to a governed first use case.
This is the shape of a first month. It works whether or not you use Palma, and it is what a security review will ask to see.
1. Inventory
List the AI clients in use and the MCP servers they are configured to reach. Their configuration files declare it. Ownerless servers go to the top of the list.
2. Connect the identity provider
Entra or Okta, over OIDC or SAML, with SCIM so groups stay in sync. From here on entitlement follows the groups you already maintain.
3. Compose by team
Connect the servers a team needs once, bundle tools and Skills into a Pack, attach it to the group. Reads open, writes held for approval, the approver named.
4. Read the first week’s record
Every call now carries the person, the agent, the client and the decision. That record is what goes to the security review, and it is the evidence an auditor asks for.
Questions
What people ask about MCP governance.
What is MCP governance?
MCP governance is the set of controls that decide which people and agents may reach which tools through the Model Context Protocol, on what terms, with whose approval, and with what record. MCP is the open standard that lets an agent use a tool; it authenticates a client to a server and defines how a tool is described. Governance is everything that leaves open: whether this person may use this tool with these arguments, whether a human should confirm it first, and what record it leaves.
Does the Model Context Protocol include governance?
No, and it is not meant to. MCP defines how a client and a server talk and how the client authenticates. It has no concept of the employee behind the client, of groups, of policy on arguments, of approval, or of an audit record across servers. Those sit in a layer above the protocol, which is what an MCP governance product is.
What is the difference between an MCP gateway and MCP governance?
A gateway is a proxy in front of some servers: it authenticates, rate-limits and logs. That is useful, and a governance layer includes it. The difference is the unit of control. A gateway governs a server; governance governs a person. Each employee gets one connector, assigned by group, carrying what they are entitled to, with policy evaluated per call and a record of who decided. A useful test for any vendor: ask to see a denied call for a named person, and the record of who approved a held one.
How is MCP governance different from AI agent security tools?
Most agent-security products discover, monitor and alert: they tell you what happened. Governance decides what is allowed before the call is made, on the arguments of the call, and holds the consequential ones for a person. The two are complementary, and many enterprises run both. What governance adds is the decision and the evidence, not another feed of findings.
Who owns MCP governance in an enterprise?
Usually a platform or AI engineering team runs it, security signs off on the policies and reads the record, identity owns the groups, and finance reads the cost. The reason it works as one layer is that none of them has to build a second system: entitlement comes from the identity provider, and the record is the same for every server and every assistant.
Does MCP governance cover Skills as well as tools?
It should, and in Palma it does through the same connector and the same permission model. A Skill is the playbook an agent follows, which makes it an instruction channel into the agent. It needs its own release process: scanned before it is served, frozen per version, entitled by group. That is Skill governance, and it has its own page.
Book a demo
See what governed AI agents look like.
A 20-minute demo on your stack. We'll show Palma working with the agents, tools and identity provider you already run.
- Enterprise security
- Role-based access
- Instant integration
Latest Blog Posts
Stay up-to-date with the latest in enterprise AI, MCP servers, and secure integration strategies.
