Skip to main content

​
Tools, rules & hooks

However a tool reaches an agent — through an Integration, a Skillset, or built in — you control whether it’s on and how it’s allowed to behave with a layered set of guardrails: the toolset ledger, rules (family-wide with per-tool overrides), and hooks (code-enforced policy gates).

​
The toolset ledger

Capabilities → Toolset lists every tool the agent has, grouped by where it came from: built-in tools, one section per integration (with per-module subsections), and one per connected MCP server. Search and filter by all / active / inactive / required. Each row shows the tool, its description, and:
  • An enable/disable toggle. A handful of tools are required for the agent to function and show a lock instead of a toggle.
  • A destructive warning marker on tools that can change or remove things.
  • Privileged vs end-user badges: privileged tools act with the admin credentials configured on the integration; end-user tools act as the person asking. Privileged tools whose integration credentials aren’t verified yet show Awaiting authorization and stay unusable until an admin completes the integration’s authorization.

​
Confirmation before acting

Tools that send, change, or remove things ask the end user to confirm before running — the conversation shows exactly what’s about to happen and waits. This is built into how each tool is classified; the highest-risk actions always confirm and that can’t be switched off.

​
Family rules

The built-in web and file tools accept family rules — one set of constraints applied to every tool in the family:

​
Per-tool rules and the effective rule

Open any tool from the ledger for its detail page, where you can override its family’s rules for just that tool. The page shows the effective rules — family rules first, overridden by anything set here — so you always see what will actually be enforced. A per-tool deny always wins: anything on a tool’s deny list is refused even if the family rules would allow it, and the ledger warns you when a per-tool allow contradicts a family deny.

​
Hooks

A hook is a code-enforced policy gate that runs at a fixed point in a tool’s lifecycle — before the call is accepted, before and after it’s sent to the vendor, and before the result reaches the agent. Unlike prompt instructions, hooks are enforced in code: the model can’t talk its way past one. A hook pairs a condition on the call’s arguments or result with an action:
  • Allow or deny (with a reason shown to the user — e.g. requires approval, out of hours, manager only).
  • Transform the arguments before they’re sent.
  • Append a message or enrich the result the agent sees.
Configure hooks on a tool’s detail page (each lifecycle slot shows what’s configured; your hook replaces any template default for that slot). The agent-wide Hooks page is a read-only ledger of every hook — which tool, which event, draft or production, where it came from — for review and audit.