Policy Rules (Governance)
manage_policy is how the assistant and your organization enforce hard guardrails on MCP tool usage.
Policy is different from preferences:
- Preferences (“memory”) are guidance: “Do X by default”.
- Policy is enforcement: “X is denied” or “X requires confirmation”, even if the user asks for it.
End users typically won’t manage rules directly-you’ll ask the LLM to evaluate policy before risky changes and to explain blocks in plain English.
What policy can do (practical examples)
Policy lets you set hard rules the LLM cannot override, even if the user asks it to. Unlike preferences (which are guidance), policy is enforcement.
Here is what you can do in practice:
- Prevent destructive operations - block the LLM from deleting tables, measures, columns, or relationships. The assistant physically cannot execute the delete, no matter how the user phrases the request.
- Enforce metadata standards - require that every new measure includes a description and a dynamic format string. The LLM must add them before the operation can proceed; it is not a suggestion.
- Require confirmation for risky edits - renames, relationship changes, or role modifications trigger a confirmation step where the assistant must ask you to approve before proceeding.
- Lock down specific models - apply stricter rules to production datasets while keeping development models open for experimentation.
- Restrict bulk operations - allow single-item edits but block batch changes (items[]) to prevent large-scale accidental damage.
- Control by model identity - let a specific model/dataset have its own rules, independent of your global policy.
How it works under the hood
Each rule has an effect:
- Allow - explicitly permit an operation.
- Deny - hard block (the LLM cannot proceed).
- Confirm - the assistant must ask you to approve before executing.
Rules can target a specific tool, an operation within a tool (e.g. "delete"), bulk vs single edits, model identity, argument values, and other conditions.
What to ask the LLM (quick prompts)
“Check policy status and summarize what’s enforced in this environment.” “Before attempting this change, evaluate whether policy would block it or require confirmation.” “This operation was blocked. Show me the rule that triggered it and explain the approved alternative.” “List the policies that apply to this model specifically (if supported).”Scopes: global vs model (and precedence)
Policy rules can be saved at two scopes:
- Global policy: applies to all models you use with this MCP server.
- Model policy: applies only to the connected model/dataset.
Precedence:
- Model-scoped rules are evaluated before global rules.
- The first matching rule (by priority) decides allow/deny/confirm.
User prompts:
“Show me the effective policy for this model: model rules first, then global.” “Create a model-scoped policy for this dataset only: require confirmation for relationship edits.”What changes depending on your org deployment
Two different “lockdowns” matter:
- Server mode (full vs read-only vs browse-only)
- Policy bundle (centrally deployed by admins)
Mode behavior (what you’ll experience)
| Mode | Availability |
|---|---|
| Full mode | AvailableAvailable |
| Read-only mode | LimitedLimited |
| Browse-only mode | LimitedLimited |
Notes: Edits locked in read-only/browse-only and in bundle-locked org setups.
Browse-only deployments are intentionally locked down; policy evaluation remains available, but policy edits are disabled.
Bundle mode (central governance)
Some orgs deploy an admin-owned policy bundle. In bundle mode:
- policy evaluation remains available,
- policy edits are locked (centrally controlled),
- and if the bundle fails to load, the server may enter a strict “lockdown” where many tools are denied until the bundle is fixed.
If you suspect bundle mode:
“Check whether policy is bundle-locked and, if so, which admin needs to update the bundle.”If you see errors like “bundle required but failed to load”:
“Explain the bundle error and what tools are still allowed. Provide the exact message I should send to the admin.”Fail-open vs fail-closed (important in incidents)
Organizations choose what happens if policy evaluation fails:
- Fail-open: allow operations when evaluation errors occur (more permissive).
- Fail-closed: deny operations when evaluation errors occur (more strict).
User prompt:
“Is policy configured fail-open or fail-closed? What happens if evaluation errors occur?”Common governance workflows (copy/paste prompts)
1) “Can we do this safely?”
“We want to rename measure ‘X’. Evaluate policy: is rename allowed, denied, or confirm-required?”2) Explain a block (fast)
“This operation was blocked. Show the matching rule id and message, and explain what change would be allowed instead.”3) Enforce metadata standards on new objects
"Create a policy rule: when creating a measure, the assistant must include a description and a dynamic format string. Deny the operation if either is missing."4) Block destructive operations
"Propose a policy that blocks deletes for schema/semantic tools and requires confirmation for renames. Render it, validate it, and only apply if edits are allowed here."5) Use built-in recipes (faster than writing from scratch)
manage_policy includes built-in recipes/templates for common patterns.
Troubleshooting
Ask for the fallback:
“Without policy tooling, what’s our safe manual guardrail process? Give me a checklist and the validation queries.”Ask:
“Show the rule id + message and propose an allowed alternative.”Ask:
“Is this fail-open or fail-closed? What is the exact evaluation error and how do we fix it?”