MCP Policies
Decide what every agent is allowed to do.
Policy at the point the call actually happens — not a document describing what should have happened. Allow, deny, hold for a human, or cap the rate, on the real arguments of a real request.
The decision
Same tool. Same team. Three different answers.
A policy is not a switch on a capability. It reads the request that was actually made — which is why one refund goes through and another one stops.
- Sarah Martinez called
get_pipelineon Salesforce CRM API Allowed - David Kim called
create_incidenton PagerDuty Alerting Confirm required - Priya Sharma called
issue_refundon Billing API Denied
What a policy decides
Four decisions, made before anything happens.
An agent asks to do something. These are the questions answered between the asking and the doing.
Allow and deny, per tool
Decide which tools an identity can reach at all. The ones that are not allowed are not offered — an agent cannot choose something it was never shown.
Rules that read the arguments
Not just which tool, but which channel, which amount, which fields. A rule can permit a refund and still stop one above a threshold.
Stop and ask a person
High-risk calls pause for a named approver rather than failing or proceeding. The agent waits; the decision belongs to someone who can be asked why.
Rate limits that hold
A retry loop is a cost and a risk. Limits cap how often a capability can be exercised, per identity, before anything downstream notices.
In the product
Governance you can see from the space.
Policies are not buried in a settings page. Open a team's space and the active count, the split between enforcing and observing, and the access decisions that just happened are all on the surface.
- Active, enforcing and observing counts per space
- Access granted and denied in the recent events feed
- Policies scoped to the Pack they govern
Rolling it out
The hard part is shipping a rule without breaking work.
Most governance fails not because the rule is wrong but because it arrives without warning. These exist to stop that.
Observe before you enforce
Run a rule in observe mode and watch what it would have done against real traffic. You find out whether it breaks someone’s work before it does.
Defaults, with room for exceptions
Set a baseline for the organisation and override it for the identities that genuinely need something different — without abandoning the baseline everywhere else.
Attached to the capability, not the team
A policy travels with the Pack it governs, so every space that installs the capability gets the rules with it instead of renegotiating them.
We see almost every company building in this space. Most are building MCP gateways for engineering teams of five or ten. Palma is a governance layer designed for enterprise scale and enterprise processes … which is why we did not just invest, we run it ourselves.
Evidence
A decision you can point at afterwards.
Enforcement is only half of it. The other half is being able to show what was decided, for whom, and why.
Every decision is recorded
Allowed, denied, held for approval — each outcome is written with the identity, the agent and the client that produced it.
Visible where the work happens
Open a space and the policy count is on the surface: how many are active, how many enforcing, how many observing.
Works with what you already run
Palma enforces at the call. Where you already have a policy decision point, it stays the authority — this is the place its answer gets applied.
Questions
What people ask about policies.
What does governing tool access actually mean?
Two decisions, not one: which tools an identity is offered at all, and what each individual call may do. Palma scopes the tools a person sees to their identity-provider group, evaluates the arguments of a call against a rule, holds sensitive actions for a named approver, and caps rates. “Read a customer record” and “read every customer record” are the same tool and different decisions.
How does this relate to MCP's own authorisation?
MCP's authorisation specification covers the client-to-server handshake: it authenticates a client to a server. It does not decide which person may use which tool with which arguments, hold a call for a human, or keep the audit record. Palma's policies are evaluated at the gateway, for calls routed through it, on top of the authentication your servers and downstream systems already do. The layers have to agree.
What can an MCP policy decide on?
Which tools an identity can reach, the arguments a call is allowed to carry, whether it needs human approval, and how often it can be exercised.
Can we test a policy before enforcing it?
Yes. A rule can run in observe mode against real traffic, recording what it would have done, before it is promoted to enforcing.
Does this replace our policy decision point?
No. Where you already run a PDP it remains the authority. Palma is where its decision gets applied, at the agent-to-tool call.
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.
