Lesson 574 of 2116
Tool Registries and Permissioned Toolsets
Teach students how an agent safely discovers tools, validates calls, and limits what any session may do.
Lesson map
What this lesson covers
Learning path
The main moves in order
- 1What the local Hermes build teaches
- 2tool registry
- 3allowlist
- 4permission tier
Concept cluster
Terms to connect while reading
Section 1
What the local Hermes build teaches
This build lab focuses on the tool registry that turns raw capabilities into permissioned agent actions. The goal is not to copy a private machine setup. The goal is to learn the architecture pattern well enough to build a small, classroom-safe version.
Tools need names, schemas, descriptions, permission levels, validators, and runtime approval rules before a model can call them safely.
Compare the options
| Hermes pattern | Student build | Risk to handle |
|---|---|---|
| Name the boundary | a registry table for five tools with inputs, outputs, risk level, and approval behavior | giving the model direct access to broad filesystem, shell, payment, or messaging actions because the prompt says to be careful |
| Keep the interface small | Start with one happy path and one failure path | Avoid a demo that only works when everything is perfect |
| Make the system observable | Log decisions, status, and errors in plain language | Do not log private data or secrets |
Build the small version
- 1Draw or write a registry table for five tools with inputs, outputs, risk level, and approval behavior.
- 2Mark which parts are user-facing, which parts are internal, and which parts require approval.
- 3Choose one low-risk workflow and implement only that workflow first.
- 4Add one failure case before adding a second feature.
- 5Write a short operator note: what the agent may do, what it must ask about, and what it must never do.
A classroom-safe skeleton inspired by the local Hermes architecture scan.
tools:
lesson_search:
inputs: {query: string}
risk: low
approval: never
send_email:
inputs: {to: email, subject: string, body: string}
risk: medium
approval: draft_then_confirm
run_shell:
inputs: {command: string}
risk: high
approval: explicit_human_onlyKey terms in this lesson
The big idea: allowlist is not decoration. It is part of the product architecture students need before an agent becomes safe enough to use with real people.
End-of-lesson quiz
Check what stuck
15 questions · Score saves to your progress.
Tutor
Curious about “Tool Registries and Permissioned Toolsets”?
Ask anything about this lesson. I’ll answer using just what you’re reading — short, friendly, grounded.
Progress saved locally in this browser. Sign in to sync across devices.
Related lessons
Keep going
Creators · 11 min
Building Your First Agentic Workflow
Move past chatbots and build a workflow where AI takes multi-step actions on your behalf. Here's the safe-by-default beginner pattern.
Creators · 11 min
Validating AI agent output against a Zod or Pydantic schema
Treat the LLM's response as untrusted input and parse it through a schema before it touches your system.
Creators · 11 min
AI and agent tool allowlist design
Design the tool allowlist for a coding agent so it can do the job without scope creep.
