Tool Access Policy

How tool availability and method permissions are inherited and enforced at runtime in meinGPT.

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

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)

Tool Management: Expanded method table in CUSTOM mode

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.

Behavior for newly shipped tools under Only Approved:

  • New core tools from the Basics category (e.g. calculator, charts, document creation) 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.

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.
Was this page helpful?