Tool policy

Tool policy is operator-controlled configuration on defineAgent({ tools }).

const support = defineAgent({
  id: "support",
  tools: {
    allowed: ["Read", "Grep", "mcp__gmail__*"],
    denied: ["Bash(rm:*)"],
    strict: false,
    preApproved: [
      "/mcp/gmail/tools/list_messages",
      "/mcp/linear/tools/*",
    ],
  },
});

The four fields

Field	Purpose
`allowed`	Adds visible worker tools using Claude Code-style patterns
`denied`	Always blocks matching tools and wins over `allowed`
`strict`	When `true`, only `allowed` tools are visible
`preApproved`	Lets matching MCP operations run without another in-thread approval card

preApproved is separate from worker visibility. A tool can be visible and still require approval.

Choose the right layer

Need	Use
Teach a procedure	Skill
Make a tool visible or invisible	`allowed`, `denied`, `strict`
Pre-approve a known MCP operation	`preApproved`
Inspect arguments before a tool runs	`pre-tool` guardrail
Restrict HTTP destinations	Agent network policy
Add an external system or action	Connector

Why policy lives in `lobu.config.ts`

Tool authority belongs to the operator, not to a prompt or local skill file.

Local SKILL.md files provide instructions and optional Nix package requirements. Tool visibility, MCP grants, network policy, and guardrails stay in operator-owned configuration.

Keeping policy in lobu.config.ts makes authority changes visible in review and reproducible through lobu apply.

Approval and sensitive actions

Connector and MCP operations may carry annotations such as destructiveHint, openWorldHint, and idempotentHint.

Prefer narrow pre-approval entries:

preApproved: ["/mcp/gmail/tools/list_messages"]

over broad wildcards:

preApproved: ["/mcp/gmail/tools/*"]

Tool policy

The four fields

Choose the right layer

Why policy lives in lobu.config.ts

Approval and sensitive actions

Read next

Why policy lives in `lobu.config.ts`