Skip to main content

Agent Hooks and Policies

The Hedera Agent Kit provides a flexible and powerful system for putting limits on tool usage and enforcing business logic, effectively enabling you to limit the functionality of AI agents through Hooks and Policies. These hooks and policies can be used to enforce security, compliance, and other business rules.

Table of Contents

Part 1: For Hooks and Policies Users

Part 2: For Policy and Hook Developers


Part 1: For Hooks and Policies Users

Quick Overview

Hooks and Policies let you customize how tools behave:
  • Hooks: Extensions that observe and modify tool execution (logging, tracking, etc.)
  • Policies: Validation rules that can block tool execution if certain conditions aren’t met
Only tools extending ToolV2 support hooks and policies. Tools that directly implement the basic Tool interface (the functional pattern) do not support these extensions. See Create Python Plugins for instructions on using ToolV2.

When Hooks and Policies are Called

Hooks can execute at 4 different points during a tool’s lifecycle:
  1. Pre-Tool Execution - Before anything happens, when parameters are passed.
  2. Post-Parameter Normalization - After parameters are validated and cleaned.
  3. Post-Core Action - After the main logic executes (e.g., transaction created), before tool execution when a transaction has been formed.
  4. Post-Tool Execution - After everything completes; after tool execution when a transaction has been signed and submitted.

How to Use Hooks and Policies

Add hooks and policies to your agent’s context during initialization:

Available Hooks and Policies

Description: Provides an immutable audit trail by logging tool executions to a Hedera Consensus Service (HCS) topic.
Autonomous Mode Only: This hook is strictly available in AUTONOMOUS mode. It will throw an error if used in RETURN_BYTES mode.
Parameters:
  • relevant_tools: List[str] - List of tools to audit (e.g., ['transfer_hbar', 'create_token']).
  • hcs_topic_id: str - The pre-created Hedera topic ID (e.g., '0.0.12345').
Description: A security policy that limits the number of recipients in transfer and airdrop operations. It blocks requests that exceed a defined threshold.Parameters:
  • max_recipients: int - Maximum number of recipients allowed.
  • additional_tools: List[str] - (Optional) Extra tools to apply this policy to.
  • custom_strategies: Dict[str, Callable[[Any], int]] - (Optional) A mapping of tool names to functions that count recipients.
Description: A restrictive policy used to explicitly disable specific tools.Parameters:
  • relevant_tools: List[str] - The list of tool methods to be blocked (e.g., ['delete_account', 'freeze_token']).

Part 2: For Policy and Hook Developers

Tool Lifecycle Deep Dive

Every tool in the kit follows a standardized 7-stage lifecycle:

Hook Parameter Structures

Each hook receives specialized parameter objects and the method name (str) representing the tool being executed.

Hooks vs. Policies

Hooks (AbstractHook)

Hooks are non-blocking extensions that observe and modify execution flow.

Policies (AbstractPolicy)

Policies are specialized Hooks designed to validate and block execution. If True is returned from a should_block... method, the Policy base class raises a ValueError.
Policy Implementation Rule: When creating a custom Policy, you should define logic in at least one of the should_block... methods. You must not override the native hook methods.

Creating New Hooks/Policies