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.
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.
