Assistant Tool Access Policy

This page explains the effective enforcement model for assistant tools 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. Is the method explicitly enabled on the assistant?

A method is only executable if all checks pass.

UI Location and Orientation

All relevant controls are in:

• Settings > Assistant Integrations
• Route: /:organizationId/settings/assistant-integrations

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.

Layer 1: Tool Availability (Organization)

In Settings > Assistant Integrations, 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.

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.

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.

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)
   • 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 assistant enabledMethodIds -> 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 tool?

"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 > Assistant Integrations, 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.

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.