TATER MCP Tool Policies
Decide which MCP tools your AI agents can call. Restrict by org, by role, by custom group. The same defense-in-depth model that gates user actions in TATER now gates AI tool invocations from Claude, Microsoft Copilot, and the stdio MCP server.
Why this matters
The TATER MCP server exposes 277 tools that read and write tenant state - create risk acceptances, run remediations, execute fleet-wide scripts, file Azure DevOps work items, post to control threads. By default, the same RBAC rules that govern human users apply to AI tool calls (Auditor read, Admin write, etc.). For most organizations that's appropriate.
For organizations that want tighter control over what AI is permitted to do - independent of what individual users can do - MCP Tool Policies provide a per-tenant gate that runs before every tool invocation. Block execute_script globally, scope create_risk_acceptance to the compliance team, allow only read-only tools for the help-desk group. Changes take effect on the next MCP call.
The policy model
Four layers, evaluated in order. Most-restrictive wins.
- Default action for new tools (organization-wide). Pick Enabled (permissive) or Disabled (strict). This decides the baseline for every tool, including new ones shipped in future TATER releases. See the section below for the two operational modes.
- Global per-tool overrides. Explicit exceptions to the default:
- In Enabled mode, the override list is
globallyDisabled- tools on it are blocked for everyone. - In Disabled mode, the override list is
globallyEnabled- tools on it are the only ones that clear the global gate.
- In Enabled mode, the override list is
- Per-role rules. For each role (Viewer / Auditor / Admin / OrgAdmin), define a list of disabled tools. Optionally, declare a strict allowlist - ONLY listed tools are allowed for that role. Allowlists are powerful and additive: a role with an empty allowlist gets nothing.
- Per-group rules. Tag members with custom group names (e.g.,
compliance-team,incident-responders) on the Users page. Define per-group disable/allow lists. A user in multiple groups gets the union of allowlists; deny wins on any conflict.
Default action for new tools
Pick the operational mode that fits your org's risk tolerance. The toggle lives at the top of the Global tab as a large green/red button.
| Mode | Default for every tool | What admins manage | Right for |
|---|---|---|---|
| ● Enabled (permissive, default) | Allowed | The globallyDisabled denylist - toggle a tool OFF (red) below to exclude it. |
Most orgs: trust the platform's per-tool role gates and only block the few high-risk tools you want to lock down (execute_script, trigger_remediation, etc.). |
| ● Disabled (strict) | Denied | The globallyEnabled allowlist - toggle a tool ON (green) below to permit it. |
Highly regulated environments. New tools shipped in future TATER releases are denied automatically until you explicitly opt them in. Zero-surprise policy. |
Flipping the mode preserves your existing per-tool decisions server-side, but their meaning inverts: in Enabled mode the toggles below set what's denied; in Disabled mode they set what's allowed. The page shows a confirmation dialog before applying the flip so you can preview the impact.
Resolution order
For every MCP call, the gate evaluates in this exact order. The first deny wins; absent any deny, the call proceeds.
| # | Check | Outcome on hit |
|---|---|---|
| 1 | Caller is SuperAdmin | Allow (bypass; rest of policy ignored) |
| 2 | newToolAction === 'enabled' AND tool is in globallyDisabled | Deny - "Tool is globally disabled by org policy" |
| 3 | newToolAction === 'disabled' AND tool is NOT in globallyEnabled | Deny - "Tool is not in the org-wide allowlist (org default: disabled)" |
| 4 | Any of caller's groups has tool in disabledTools | Deny - "Tool disabled for group X" |
| 5 | Caller's role has tool in disabledTools | Deny - "Tool disabled for role X" |
| 6 | Any of caller's groups has a non-empty allowedTools AND tool not in any of them | Deny - "Not in allowlist for any of user's groups" |
| 7 | Caller's role has a non-empty allowedTools AND tool not in it | Deny - "Not in allowlist for role X" |
| 8 | (Default) | Allow |
Configuring policies in TATER Manage
Open manage.tatersecurity.com → MCP Tool Policies. The page has four tabs:
Global tab
At the top: a large green/red Default action for new tools toggle (the policy mode selector from above). Below it: all 277 tools grouped by category (Reading & Discovery, Compliance Actions, GRC Modules, Documentation, Federal / DoD ATO, Operations, Identity & Verification, Org Context). Each tool shows its name, a one-sentence description, a write badge if applicable, and a green ON / red OFF pill button. The tool row's background tints green or red so on/off state is scannable at a glance.
Click the pill to flip the tool's state. The meaning of ON / OFF depends on the policy mode you picked: in Enabled mode, ON means “allowed (default)” and OFF means “in globallyDisabled[]”; in Disabled mode, ON means “in globallyEnabled[]” and OFF means “denied (default)”.
Recommended starting point: review the Operations category - execute_script and create_script can run arbitrary code on up to 500 endpoints. Many orgs disable these globally (toggle to OFF in Enabled mode) and re-enable per-group as needed.
By Role tab
One collapsible card per role. At the top of each card: an ALLOWLIST ON / DENYLIST toggle button that flips the role between denylist mode (toggle a tool OFF below to deny it; everything else is allowed) and allowlist mode (toggle a tool ON below to allow it; everything else is denied). Allowlist mode is the strongest mode: a role with an empty allowlist gets zero tools.
Each per-tool control is a green ON / red OFF pill showing the effective state for that role. In denylist mode, OFF means “in this role's disabledTools[]”. In allowlist mode, ON means “in this role's allowedTools[]”.
Use case: "Auditors should only be able to read; never write." → In Auditor card, flip ALLOWLIST ON, then toggle ON each list_* / get_* / search_* tool.
By Group tab
Add a custom group name (e.g., compliance-team). Group names are normalized to lowercase + hyphens. The new group appears below with the same ALLOWLIST ON / DENYLIST mode toggle and per-tool ON/OFF pills as roles. Members are tagged with groups via the Users page (assign multiple groups by comma-separating).
Use case: "Only the incident-response team can trigger remediations." → Create incident-responders group with trigger_remediation + execute_script in its allowlist; add trigger_remediation to the global denylist; tag IR team members with the group.
Preview tab
Test the policy without making real MCP calls. Pick a role + groups + tool, click Run preview. The result shows Allow/Deny + the exact reason from the resolution order table.
Tagging members with groups
Group membership lives on each user's OrgMembership record. Two ways to set it:
- Manage UI (recommended): TATER Manage → Users → click a user → edit groups field. Comma-separated list, e.g.,
compliance-team, incident-responders. - API:
PUT /api/organizations/:id/members/:membershipIdwith body{ orgRole: "Admin", groups: ["compliance-team"] }.
What users see when a tool is blocked
The MCP server returns a polite error to the AI agent:
⛔ Tool "execute_script" is blocked by your organization's MCP policy.
Reason: Tool disabled for role Auditor
An administrator can review and adjust tool policies in
TATER Manage → MCP Tool Policies.The AI agent sees this in the same channel as any other tool error and typically explains it to the user in plain language. The denied call is recorded in the audit log so admins can see what was attempted.
Audit log
Every policy save (PUT /api/mcp/policy) is recorded in the audit log with action update, entity type McpToolPolicy, and metadata showing how many tools/roles/groups were configured. View the trail in TATER → Activity Log, filtered by entity type. The audit log is HMAC-signed (when AUDIT_SIGNING_KEY is set) for tamper evidence.
Best practices
- Start permissive, tighten over time. Out of the box, no policy is configured and all role-based RBAC continues to apply. Add deny rules as you observe AI behavior in your environment.
- Use the Preview tab obsessively. Allowlists in particular have non-obvious resolution. Always preview a representative role + group combo before saving.
- Globally disable destructive tools.
execute_script,trigger_remediation,create_risk_acceptance,auto_populate_poam- these get a global disable in many orgs, with selective re-enable per group. - Document why. When you disable a tool, drop a note in the org's TATERpedia under
policy/mcp-restrictionsexplaining the reason. Future you will thank present you. - SuperAdmin bypass is intentional. SuperAdmin is for break-glass platform operators. Don't rely on policy to constrain SAs - use SuperAdmin assignment sparingly and audit it.