Permissions and risk

Every tool call goes through the policy engine before anything is sent to your API. The engine decides one of three outcomes: allow, deny or require confirmation. The decision and its reason are stored with the execution.

Risk levels

Every tool has a risk level. PipMCP assigns it from the HTTP method, the mapped action and the operation's semantics; AI analysis can raise a level but never lower it. You can change it on the tool page.

Level	Name	Examples
0	Read-only	search_customers, get_invoice
1	Low-impact write	create_customer, update_contact
2	External effect	send_email, submit_order
3	Destructive	delete_customer, cancel_subscription
4	Financial or irreversible	refund_payment, book_invoice

Endpoint presets

Each MCP endpoint has a preset that applies when no policy matches:

Preset	Behaviour
Read only	Only level 0 runs; everything else is denied.
Safe writes (default)	Levels 0–2 run; levels 3–4 need confirmation.
No destructive actions	Levels 0–2 run; levels 3–4 are denied.
Confirm external effects	Levels 0–1 run; levels 2–4 need confirmation.
Custom	Your policies decide; unmatched calls behave like Safe writes.

Policies

Policies are workspace rules under Policies. Each has an effect (deny, require_confirmation or allow), a priority and conditions. All conditions of a policy must match. Available conditions:

• Endpoints, integrations, tools, connections, tokens: limit the rule to specific items.
• Canonical operations and resources: e.g. every delete on customer, across all APIs.
• Risk range: minimum and/or maximum risk level.
• Clients: match the AI client name (for example claude or cursor).
• Input rules: compare an argument with eq, neq, gt, gte, lt, lte, in, contains or exists. For example: require confirmation when amount is greater than 1000.
• Time window: days of the week and a time range in a given timezone.

Access roles

Access roles decide which tools a person can see. They are separate from the workspace roles on the team page, which only control the dashboard.

On an integration's Tools tab, add a role and choose a starting set: reads only, no destructive or financial actions, every enabled tool, or an empty set you fill in yourself. That role then limits that integration. Tools you have not granted are left out of the tool list, and calling one comes back as an unknown tool. A later import does not add the new tools to the role.

A link with no role can use every tool the endpoint exposes. Assign a role when you create a personal link, or on the endpoint page afterwards, so people in the office get different sets. Use one link per person. Presets and policies still decide whether a visible tool may run or needs confirmation. A role that does not limit an integration leaves that integration's tools available.

Evaluation order

The engine is deterministic. For each call it evaluates, in this order:

1. Deny – the first matching deny policy blocks the call.
2. Tool set to always confirm – the tool's own confirmation setting is always.
3. Require confirmation – the first matching confirmation policy.
4. Allow – the first matching allow policy lets the call run.
5. Endpoint preset – the table above, based on the tool's risk level.

A deny always wins. A tool set to never confirm skips a preset's confirmation only for risk levels below 3; destructive and financial actions still follow the preset.

Confirmation

A protected action is never executed silently. What happens depends on the client.

Clients with elicitation (MCP 2026-07-28)

If the client declares the elicitation capability, the tool call returns input_required with a confirmation request. The client asks the user, then repeats the call with the answer and the signed requestState. The state is bound to the token, tool and exact arguments, valid for 10 minutes and usable once. Protocol details: Connect a generic MCP client.

Other clients: dashboard approval

The call is not executed and the tool returns:

{
  "code": "CONFIRMATION_REQUIRED",
  "message": "This action requires human approval and was not executed. The \"Safe writes\" preset requires confirmation for risk level 3 actions.",
  "details": [{ "field": "approval_id", "message": "01J9Z3K8Q4..." }],
  "suggested_action": "Ask the user to approve it in the PipMCP dashboard (Executions → Pending approvals), then call the tool again with the same arguments."
}

1. Open Executions and filter by Pending approval, or follow the banner.
2. Review the tool, the redacted input and the reason, then Approve or Reject.
3. Ask the agent to run the same action again. The retry must use the same tool, the same arguments and the same token, within 24 hours of approval. Each approval can be used once.

If the endpoint's approval mode is set to None, no approval is created and the call is simply refused.

Tips

• Start with Safe writes and read the executions log for a few days before loosening anything.
• Use a separate endpoint with Read only for exploratory or untrusted agents.
• Use input rules for business limits, such as confirming refunds above a threshold.
• Combine a client condition with deny to keep specific clients away from specific tools.