Solutions · AI agents · Permissions & guardrails

Agents that respect your boundaries.

Every tool LM-Kit ships exposes machine-readable metadata: which category it belongs to, whether it reads or writes, whether it touches the network, what risk level it carries, whether it is idempotent. ToolPermissionPolicy turns that metadata into centralised access control, with allow rules, deny rules, risk ceilings, and approval workflows.

Start building free API reference

Typed tool metadata Wildcard rules Approval workflows

RiskLevel

Low / Medium / High / Critical. Set a ceiling per agent profile.

SideEffect

None, LocalRead, LocalWrite, NetworkRead, NetworkWrite, Irreversible.

DefaultApproval

Never / Conditional / Always. Suggested baseline per tool.

Why guardrails matter

A tool catalogue is a blast radius.

The moment you give an agent the file system, the network, and the shell, you have to decide what it is allowed to do. "Read its way through the docs" is fine. "Run rm -rf" is not. Without typed metadata and a policy layer, that decision lives as code review folklore.

Allow / Deny / Require approval

ToolPermissionAction covers the three useful outcomes. Default is approval-required for tools rated High or Critical risk.

Wildcard rules

Allow filesystem_*, deny filesystem_delete. Atomic tool naming makes wildcards a real security primitive.

Category gates

AllowCategory("data", "text") + DenyCategory("io", "net") ships a safe-chat profile in two lines.

Risk ceilings

SetMaxRiskLevel(ToolRiskLevel.Low) rejects every tool above the threshold regardless of category. A defence-in-depth knob.

Read-only profiles

BuiltInTools.GetReadOnly() returns every tool with no state mutation. Build research agents that cannot break anything.

Approval workflows

A RequireApproval rule pauses execution and emits an approval event. Hook it to a Slack bot or a pull-request style UI.

Two profiles

Safe chat. Dev assistant.

A safe chat profile only allows pure-computation tools. A dev assistant profile grants more, but with deny rules and approvals on the dangerous bits. Both are five-line policies.

Lock the agent down to pure-computation categories, deny I/O and network, and cap the risk level.

SafeChatProfile.cs

using LMKit.Agents.Tools;

var chatPolicy = new ToolPermissionPolicy()
    .AllowCategory("data", "text", "numeric", "utility", "security")
    .DenyCategory("io", "net")
    .SetMaxRiskLevel(ToolRiskLevel.Low);

var agent = Agent.CreateBuilder(model)
    .WithTools(t => { foreach (var tool in BuiltInTools.GetAll()) t.Register(tool); })
    .WithPermissionPolicy(chatPolicy)
    .Build();

Grant broader access with wildcard allows and targeted denies, and require approval for shell execution.

DevAssistantProfile.cs

using LMKit.Agents.Tools;

var devPolicy = new ToolPermissionPolicy()
    .AllowCategory("data", "text", "numeric", "utility", "security")
    .Allow("filesystem_*")                              // allow all filesystem tools
    .Deny("filesystem_delete")                         // but never delete
    .Allow("http_get", "http_head")                    // read-only HTTP
    .Deny("http_post", "http_put", "http_delete")       // no mutating HTTP
    .Allow("websearch")
    .RequireApproval("process_*");                      // shell exec needs human OK

Query before you register

Filter the catalogue by metadata.

The built-in tool registry exposes filters by risk, category, and read-only status. Use them to compose an allow-list rather than write a deny-list.

QueryCatalog.cs

using LMKit.Agents.Tools.BuiltIn;

var safeOnly  = BuiltInTools.GetByMaxRisk(ToolRiskLevel.Low);
var ioTools   = BuiltInTools.GetByCategory("io");
var readers   = BuiltInTools.GetReadOnly();

// Compose an allowlist for a research agent.
var research = readers
    .Where(t => t.Category is "data" or "document" or "text" or "net")
    .Where(t => t.RiskLevel <= ToolRiskLevel.Medium);

Versus the alternatives

Most frameworks treat tools as opaque.

LangChain Tools

No standardised metadata. Risk and side effects are documented in prose. Permission policies are bring-your-own.

Semantic Kernel

Plugin filters exist but operate on names and method signatures, not on declared side-effect categories.

LM-Kit Permissions

Every built-in tool ships IToolMetadata. Custom tools declare their own. ToolPermissionPolicy reasons over both. Audit trails come for free.

Related capabilities

Compose with middleware and resilience.

Tools & function calling

The full tool catalogue and how to extend it with custom tools.

Tools page

Filter pipeline

Wrap tool invocations in middleware for redaction, logging, or salvage.

Filter pipeline page

Secure agent tool access

How-to guide combining policies, approvals, and tracing.

How-to guide

Tool permission policies glossary

Conceptual reference for the permission model.

Glossary entry

Demos & docs

Build it. Read it. Try it.

Working console demos on GitHub, step-by-step how-to guides on the docs site, and the API reference for the classes used on this page.