---
title: "Tool Access Policy"
description: "How tool availability and method permissions are inherited and enforced at runtime in meinGPT."
canonical_url: "https://meingpt.com/en/docs/admin-guide/tool-access-policy"
language: en
---

# Tool Access Policy

This page explains the **effective enforcement model** for tool access in meinGPT:

- Organization-wide admin settings
- Tool-specific admin overrides
- Assistant-specific method selection
- Runtime enforcement in chat

This page covers only **which methods** a tool may execute. For **which resources** (e.g. which folder, mailbox, or calendar) those methods can reach, see [Scope Configuration for Tools](/en/docs/platform/tool-scope-policy).

## Important Security Note

meinGPT currently does **not** support interactive AI permission prompts at runtime (no built-in "Should I execute this now?" step).

This means:

- If a method is enabled, the AI can execute it within prompt constraints without an extra user approval dialog.
- There is currently no built-in per-action permission popup.

Recommendation:

1. Use `Read only (READ_ONLY)` as the default.
2. Enable `write`/`dangerous` only when the risk is explicitly understood and accepted.
3. Grant critical methods only in a targeted, per-tool manner.

## Overview

Final permission for a tool method call is computed as an intersection:

1. Is the tool available at organization level?
2. Is the method allowed by global policy?
3. Is the method allowed by tool-specific admin overrides?
4. If the chat runs through an assistant: is the method explicitly enabled there?

A method is only executable if all applicable checks pass — check 4 only applies when an assistant is involved. For a connector used directly in a chat with no assistant, checks 1–3 alone decide.

## UI Location and Orientation

All relevant controls are in:

- `Settings > Tool Management`
- Route: `/:organizationId/settings/tool-management`

Notes:
- Method categories (`read`, `write`, `dangerous`) are shown in grouped sections in each tool detail.
- The first screenshot shows the top control area: Tool Availability (`All Tools`/`Only Approved`) and global Method Policy (`READ_ONLY` to `CUSTOM`).
- The second screenshot shows the expanded per-method table of a tool; it is only available when policy is set to `CUSTOM`.

![Tool Management: Top modes (Tool Availability and global Method Policy)](/images/platform/tool-access-policy-top-modes.png)

![Tool Management: Expanded method table in CUSTOM mode](/images/platform/tool-access-policy-table.png)

## Layer 1: Tool Availability (Organization)

In **Settings > Tool Management**, admins decide which tools are generally available.

- `All Tools`
  All current and future tools are available.
- `Only Approved`
  Only explicitly approved tools are available.

Notes:
- Applies to BUILTIN, EXTERNAL_MCP, and CUSTOM_MCP tools.
- If a tool is unavailable here, it is removed server-side before chat runtime.
- For **user-added custom MCP servers** (see [Custom MCP Server](/en/docs/integrations/custom-mcp-server)): a user can still create and save their own MCP server connection under *Settings → Connectors* – it shows as active there. However, once the `custom-mcp` capability is disabled here, that server is removed server-side from every chat/assistant and cannot be executed by **any user** in the organization, regardless of who added it.
- The **Custom MCP** switch only appears when Tool Availability is set to `Only Approved`. With `All Tools`, custom MCP servers are automatically usable for everyone and cannot be disabled separately.

Behavior for newly shipped tools under `Only Approved`:
- New core tools from the `Basics` category (e.g. calculator, charts, documents) are available automatically as soon as meinGPT ships them.
- If you disable such a tool, it stays disabled — including future updates.
- New connectors and databases are NOT enabled automatically; they always require explicit approval.

## Layer 2: Global Method Policy (Organization)

With `Only Approved`, admins can also set a global method policy:

- `Read only (READ_ONLY)`: `read` only
- `Read & modify (READ_WRITE)`: `read` + `write`
- `Full access (FULL)`: `read` + `write` + `dangerous`
- `Per-tool settings (CUSTOM)`: granular per-method control

Important:
- This policy is an upper bound.
- Disallowed modes are marked unavailable at admin layer.
- Categories come from each tool definition (backend) and are exposed in UI as `read`/`write`/`dangerous`.

Important for the combination with tool availability:
- `CUSTOM` is only effective when Tool Availability is set to `Only Approved`.
- With `All Tools`, the allowlist is inactive and new tools are automatically available.
- If you switch back to `Only Approved`, the stored method policy applies again as upper bound.

## Layer 3: Per-tool Method Overrides (CUSTOM only)

With `CUSTOM`, admins can enable/disable specific methods per tool.

Rules:
- `read`/`write` are allowed by default unless explicitly disabled.
- `dangerous` is blocked by default unless explicitly enabled.

This allows targeted control over send/delete/high-impact methods.

Caveat: a method restriction only blocks that exact method call - it does not check whether a different, still-enabled method of the *same* tool can produce an overlapping effect through its own inputs. Example: Google/Outlook Calendar expose `calendar_create_event` (`write`, enabled by default) and `calendar_invite_attendees` (`dangerous`, blocked by default). Blocking `calendar_invite_attendees` stops that specific action, but `calendar_create_event` independently accepts an `attendees` field and sends the same invitation notifications when creating an event - this is not gated by the `calendar_invite_attendees` setting. When restricting a method, check what that method's *inputs* allow, not just its name.

## Layer 4: Assistant-level Method Selection

In the assistant editor, users can select methods per tool.

This selection is stored as `enabledMethodIds` and acts as an additional restriction:

- If `enabledMethodIds` exists, **only** listed methods are enabled.
- Unselected methods stay disabled even if globally allowed.

This layer only exists for assistants today. A connector enabled directly in a chat with no assistant has no equivalent method-level restriction — only Layers 1–3 apply there.

## Runtime Enforcement in Chat

When chat starts, the backend computes:

1. Filter tools by organization availability policy.
2. For each BUILTIN tool, derive effective methods from:
   - assistant selection (`enabledMethodIds`) — only relevant if the chat runs through an assistant
   - global policy
   - CUSTOM overrides
3. Register only the resulting method set in Toolkit.

Result:
- Methods outside that final set cannot be called by the model.

## Precedence (highest first)

1. Tool unavailable (organization policy) -> full tool blocked
2. Method blocked by admin policy/override -> method blocked
3. Method not in `enabledMethodIds` (only relevant with an assistant) -> method blocked
4. Remaining methods are executable

## Common Misunderstandings

### "I disabled a method but it still executed."

Check:

1. Was the assistant saved after changes?
2. Is the method actually absent in `enabledMethodIds`?
3. Is chat using the same assistant version?
4. Is similar behavior available via another enabled method - either of a different tool, or of the *same* tool (e.g. an event-creation method that itself accepts an attendees/recipients field)?

### "Why is a method not selectable in assistant config?"

It is likely admin-locked (`isEnabledByAdmin = false`).

## Scope of Method Policies

- Method-level policies apply to BUILTIN tools with defined methods.
- EXTERNAL_MCP/CUSTOM_MCP are governed at tool availability level.

Practical impact:

1. BUILTIN: methods can be controlled granularly.
2. EXTERNAL_MCP: currently tool-level enable/disable only, no method-level admin overrides.
3. CUSTOM_MCP: currently capability-level toggle (`custom-mcp` on/off), no method-level admin overrides. This single switch applies to **all** custom MCP servers any user in the organization has added – there is no way to block individual users' servers separately. If an admin disables it, users can still create new custom MCP server connections under *Settings → Connectors*; those connections simply can no longer execute in any chat.

## Concrete Example (End-to-End)

Example target:
- Allow a CRM tool, but only contact read operations.
- Keep update/delete methods blocked.

Flow:

1. In `Settings > Tool Management`, set Tool Availability to `Only Approved`.
2. Set Method Policy to `CUSTOM`.
3. Enable the CRM tool (e.g., Salesforce/HubSpot).
4. Keep `read_contacts` enabled.
5. Disable methods like `update_contact` and `delete_contact`.
6. Save assistant and additionally restrict to required methods in `enabledMethodIds`.

Result:
- The assistant can read contacts.
- Write/delete methods are not registered in Toolkit and cannot execute at runtime.
- If the same connector is used directly in a chat with no assistant instead, the same steps 1–5 (organization policy + CUSTOM overrides) still apply; step 6 (the extra `enabledMethodIds` restriction) doesn't apply, since there's no assistant-level equivalent.

## Recommended Admin Rollout

1. Start with `Only Approved`.
2. Set method policy to `CUSTOM`.
3. Enable only required tools.
4. Allow `dangerous` only explicitly per method.
5. Let assistant owners further narrow methods per assistant.