MCP and Skill Gateway
One governed connection for every tool and every playbook.
Your MCP servers stay where they are. Palma sits in front of them and hands each person the tools they are entitled to — and the Skills that say how your company actually uses them.
Architecture
Many assistants. One place the rules live.
Whatever your teams open, the request arrives at the same connector, is checked against the same policies, and is recorded in the same place.
Who calls
People
Your employees
Signed in through your IdP, in whatever client they prefer.
Non-person entities
Your service agents
Each one registered, and each one with a named sponsor.
In the clients they already use
Claude
ChatGPT
Copilot
Cursor
Gemini
…and Codex, Windsurf, JetBrains, Zed, Cline, Continue, Roo Code, Amazon Q, LM Studio
The single point of control
One governed connector
One endpoint per identity, carrying every Skill and every MCP that person is entitled to — and nothing else.
- Identity
- Policy
- Approval
- Audit
What they reach
Skillsthe playbooks agents follow
- month-end-close
- incident-triage
MCPthe tools agents act through
- Salesforce CRM
- Data Warehouse
Why it matters
Capability and know-how, delivered together.
Most gateways move tools. A tool on its own still leaves everyone to work out how your company uses it — which is the part that decides whether an agent is useful or just busy.
One connection carries both halves
A tool is what an agent can do. A Skill is how your company does it. Both reach every assistant through the same governed endpoint, so people get the capability and the know-how together.
Governed by the same machinery
Skills are scoped to a space by exactly the rules that scope tools. There is no second permission model to maintain, and no gap between them for something to slip through.
Runs on your infrastructure
Docker, Kubernetes or bare metal, inside your network and in front of your own MCP servers. Your IdP, your policies, your audit trail.
Spaces
A governed workspace per team, not per person.
Each team gets a space that composes tools from several MCP servers into one endpoint. Health, success rate and error counts sit on the front of every card, so a space that is degrading is visible before anyone files a ticket.
- Compose one endpoint from many MCP servers
- Filter which tools each identity can even see
- Owner, health and stage on every space
MCP servers
Built for the systems you already run.
Enterprise authentication, composition and enforcement at the point every agent-to-tool call passes through.
Plugs into the identity you already run
OIDC and SAML SSO, SCIM provisioning and just-in-time user creation. Access follows the groups your directory already maintains.
Reaches servers that were never built for you
Seven outbound auth strategies, including RFC 8693 token exchange, vault-held credentials and gateway identity — so a server that only accepts an API key is still reachable without handing that key to anyone.
One endpoint from many servers
Spaces compose tools from multiple MCP servers into a single endpoint, and filter which tools each identity can even see.
Execution policies, not just permissions
Allow and deny, approval requirements, parameter rules and rate limits. Run a rule in observe mode first and see what it would have done before it starts enforcing.
Three-principal audit
Every call records the user, the agent and the host client together — so "who did this" has an answer that survives a review.
Notices when a server changes
Tools are discovered automatically, with surface snapshots and change detection, so a server quietly gaining a new capability is something you find out about.
Policies and access
See what a policy would do before it does it.
Open a space and the governance is on the surface: how many policies are active, how many are enforcing versus observing, which servers are healthy, and every access decision as it happens.
- Run a rule in observe mode, then promote it to enforcing
- Access granted and denied, recorded per call
- Cost and token usage per space, alongside the controls
Approvals and change control
Someone owns the decision, and the decision is on the record.
Enforcement is only half of it. The other half is who can change a rule, what happens while a call is waiting, and whether you can reconstruct either one later.
Risky calls stop and wait
An approval policy holds the call at the gateway and routes it to the people who own that decision. The agent gets an answer, not a silent failure, and the wait is recorded with the call it belongs to.
Standing decisions, not standing access
Pre-approvals cover the cases your team has already reasoned about, scoped to an identity, a tool and an expiry — so review effort goes to what is genuinely new instead of to the same request every week.
A rule change is itself a governed act
Policies are versioned and every edit records who made it and when. The rule that allowed a call is reconstructable months later, which is the question an auditor actually asks.
Observe before you enforce
Run a new rule in observe mode against live traffic and read what it would have blocked. Promote it to enforcing once the evidence is in, rather than discovering the blast radius in production.
Skills
Your best way of working, on everyone's agent.
Skills are versioned, scanned and scoped by the same governance that controls tools — and they arrive without anyone installing anything.
Distributed over the open standard
Skills travel over the open standard as SEP-2640 resources, with a meta-tool path for clients that have not adopted it yet — one distribution channel for every MCP-capable client instead of an adapter per vendor.
Nothing for anyone to install
Point a client at a space and the right Skills are simply there. Publish a new version and connected clients pick it up on their next session.
Scanned before they ship
Secrets are stripped before a version is stored, and deterministic rules for injection, exfiltration and privilege escalation gate what gets served. A blocked version is never handed to an agent.
Versions are immutable
Every publish is a snapshot. Nothing changes underneath an agent mid-flight, and you can always go back.
Scoped like everything else you own
Keep a Skill private to your tenant, share it with named partners, or publish it broadly. The resolver enforces the tier.
Packaged with the tools they need
A Skill that requires tools can only ship inside a Pack — so it can never land in a space without the access it assumes it has.
Activity and audit
Who did this has an answer.
Every call records the person, the agent acting for them and the client it came through. A reviewer reads it as a sentence rather than reconstructing it from three systems.
- User, agent and host client on every entry
- Failures and their reason, not just a status code
- Filter by space, agent, server or status across the org
Palma gave our agents governed superpowers. We are an investor and a customer because Palma solves one of the hardest problems in AI right now. Agent governance at scale.
Questions
What people ask about the gateway.
What is an enterprise MCP gateway?
A gateway sits between the AI assistants people use and the MCP servers that expose your systems, so access and policy are handled once instead of once per client. Palma composes approved tools from several servers into a Space per team, hands each person the subset their identity-provider group entitles them to, evaluates policy on the actual arguments of every call, holds selected calls for approval, and records who did what, through which client. Your servers stay where they are.
Does the gateway find MCP servers we don't know about?
No. Discovery and change detection cover the servers connected to the gateway: Palma finds their tools and notices when a connected server's tool surface changes. It does not find unmanaged servers on someone's laptop. That is an endpoint and network question, and the security page says how to approach it.
Does Palma replace our MCP servers?
No. Palma sits in front of them as a single governed endpoint and keeps the protocol intact.
What is the difference between a tool and a Skill?
A tool is a capability — what an agent can do. A Skill is a playbook — when and how to do it. Palma distributes and governs both through the same connection.
Do users have to install anything to get Skills?
No. Skills are distributed over the open standard as SEP-2640 resources, with a meta-tool path for clients that have not adopted it yet. Either way, pointing an MCP-capable client at a Palma space delivers the Skills that identity is entitled to.
Does it work with our identity provider?
Yes. OIDC and SAML SSO with SCIM provisioning and just-in-time user creation, against Entra, Okta or any OIDC provider.
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.
