Tool Policy

Control which tools your agents can use with profiles, groups, and allow/deny lists

Not every agent needs every tool. A customer service agent should not have shell access. A coding agent does not need platform moderation tools. Tool policies let you give each agent exactly the tools it needs — and nothing more.

Profiles

A profile is a named set of tools that serves as your starting point. Choose the profile that best matches your agent’s role, then fine-tune with allow and deny lists.

General-purpose profiles

These five profiles cover the vast majority of agent configurations. Pick one and customise it with allow / deny.

Profile	Tools Included	Best For
minimal	read, write	Restricted agents with basic file access
coding	read, edit, write, grep, find, ls, apply_patch, exec, process	Development and coding agents
messaging	message, session_status	Agents that only send messages
supervisor	agents_manage, obs_query, sessions_manage, memory_manage, channels_manage, tokens_manage, models_manage, skills_manage, mcp_manage, heartbeat_manage	Fleet management and administration
full	All tools (no restrictions)	Unrestricted agents — this is the default

The full profile is the default. If you do not configure a tool policy, your agent has access to every available tool. For production deployments, consider choosing a more restrictive profile and adding only what your agent needs.

Specialised “minimal” presets for non-interactive runs

Two extra profiles exist specifically for code paths that fire without a human in the loop — scheduled jobs and periodic heartbeats. They are opt-in (profile: cron-minimal on a CronJob or profile: heartbeat-minimal on heartbeat config) and never apply silently as a default.

Profile	Tools Included	Where it applies
cron-minimal	web_search, message, read, write, ls, memory_store, memory_search, cron, discover	Set on a CronJob to constrain what a scheduled run can do
heartbeat-minimal	message, memory_store, memory_search, discover	Set on the heartbeat config so the periodic wake-up cannot do much beyond send a message and update memory

Both presets are deliberately narrow. Expect to add a few extras per job with allow — the *-minimal suffix signals “opinionated default, customise per caller”, not “permanent ceiling”.

Tool Groups

Instead of listing individual tools in your allow and deny lists, you can use groups to manage entire categories at once. Each group expands to a specific set of tools.

Group	Tools	Purpose
group:coding	read, edit, write, grep, find, ls, apply_patch, exec, process	All file and shell tools
group:web	web_fetch, web_search, browser	All web access tools
group:browser	browser	Browser automation only
group:memory	memory_search, memory_get, memory_store	All memory tools
group:scheduling	cron	Scheduling tools
group:messaging	message	Messaging tools
group:sessions	sessions_list, sessions_history, sessions_send, sessions_spawn, session_status, session_search, subagents, pipeline	All session and agent tools
group:platform_actions	discord_action, telegram_action, slack_action, whatsapp_action	All platform moderation tools
group:supervisor	agents_manage, obs_query, sessions_manage, memory_manage, channels_manage, tokens_manage, models_manage, skills_manage, mcp_manage, heartbeat_manage	All supervisor tools

The DAG (LCD) context engine’s ctx_* recall tools (ctx_search, ctx_inspect, ctx_expand) are active in the default DAG mode (contextEngine.version defaults to "dag") and are never-export. In the opt-in pipeline mode, use session_search (part of group:sessions) instead.

You can mix individual tool names and group names in the same allow or deny list.

Configuring Tool Policy

Add a toolPolicy section under skills in your configuration file. Here are three common setups:

Coding agent with web access:

skills:
  toolPolicy:
    profile: coding
    allow:
      - group:web
      - group:memory

This agent starts with the coding profile (file tools and shell) and adds web access and memory tools on top.

Customer service agent — messaging only, no file access:

skills:
  toolPolicy:
    profile: messaging
    allow:
      - group:memory
    deny:
      - exec

This agent can send messages and search memory, but has no shell access or file tools. The deny list explicitly removes exec even though it is not in the messaging profile — this is a defensive measure in case the profile changes in a future version.

Supervisor agent:

skills:
  toolPolicy:
    profile: supervisor
    allow:
      - group:web

This agent can manage the fleet (agents, sessions, memory, channels, tokens, models, skills, MCP servers, heartbeats) and also has web access for checking external services.

How Resolution Works

When Comis determines which tools an agent can use, it follows a three-step process:

1. Start with the profile — load the tools defined by the named profile
2. Add the allow list — include any additional tools or groups from the allow field
3. Remove the deny list — exclude any tools or groups from the deny field

The deny list always wins. If a tool appears in both the profile and the deny list, it is denied. This means you can safely use a broad profile and then remove specific tools you do not want.

The deny list is applied last, so it takes priority over everything else. This is useful when you want to use a broad profile like coding but need to remove one specific tool — for example, denying exec to prevent shell access while keeping all other coding tools.

Example Resolution

Given this configuration:

skills:
  toolPolicy:
    profile: coding
    allow:
      - group:web
    deny:
      - exec
      - browser

The resolution works like this:

1. Profile coding: read, edit, write, grep, find, ls, apply_patch, exec, process
2. Add group:web: adds web_fetch, web_search, browser
3. Deny exec, browser: removes both from the final set

Result: read, edit, write, grep, find, ls, apply_patch, process, web_fetch, web_search

Per-Skill Tool Restrictions

In addition to the agent-level tool policy, individual skills can restrict which tools are available while they are active. This is set with the allowed-tools field in the skill manifest — a space-separated string in the six-field manifest:

---
name: research-assistant
description: "Search the web and summarize findings"
allowed-tools: "web_search web_fetch read"
---

When this skill is active, the agent can only use the three listed tools — even if its tool policy allows more. This adds a second layer of restriction on top of the policy.

Skills Overview

Understanding the three types of skills

Config Reference

Full configuration reference including tool policy

Built-in Tools

All built-in tools documented

Agent Tools

Complete platform tool reference