Execution Authorization Layer for AI Systems

Machine actions
need authority.

KiLu is the execution authorization layer for AI systems.
Add ALLOW / REQUIRE_CONFIRM / BLOCK before tools, browser actions, and high-risk execution.

Agent / Framework ↓ Proposed Action ↓ KiLu ALLOW  |  REQUIRE_CONFIRM  |  BLOCK ↓ Execute (bounded, receipt-linked)
Explore the SDK → Read Architecture See Evidence
Published SDK on npm 3 live integration proofs Real control plane path Decisions durably recorded Signed receipts for allowed actions
Get Started

Choose your path

For Developers
Add authorization before execution

Wrap tool handlers in MCP, LangGraph node calls, or browser action hooks with a deterministic ALLOW / REQUIRE_CONFIRM / BLOCK layer.

Explore the SDK →
For Security / Assurance
Separate reasoning from authority

KiLu enforces that no component can plan, authorize, and execute in the same loop. Signed receipts. Explicit denial records. Fail-closed by design.

Review Security Model →
For Evaluators / DD
Inspect grants, receipts, evidence

Grants prove bounded authority. Receipts prove authorized execution. Evidence remains separable from reasoning and verifiable offline.

See Evidence →
Quickstart

Get started in minutes

Local examples run with a mock authority layer. Real control plane path is available.

$ npm install @kilu-control/sdk
TypeScript 
import { KiluClient } from "@kilu-control/sdk";

const kilu = new KiluClient({
  baseUrl: process.env.KILU_BASE_URL!,
  apiKey:  process.env.KILU_API_KEY!,
});

const result = await kilu.submitIntent({
  actor:  "agent:browser",
  action: "browser.click",
  target: "#confirm-purchase",
});

if (result.outcome === "ALLOW") {
  // execute — grant is bounded and receipt-linked
}
MCP Tool Gate LangGraph Approval Gate Browser Approval View on GitHub
Works With

Integrates into your existing stack

MCP
Gate tool execution at the handler level. Block or confirm before any tool call runs.
Tool-level gate
LangGraph
Wrap graph nodes with an approval step. Drive confirm/block flows without framework changes.
Node-level approval
Browser Agents
Intercept clicks, submissions, and navigation before they execute. Works in any browser automation layer.
Action interception
Why KiLu

Why KiLu vs other approaches

Most approaches record what happened or hint what to avoid. KiLu decides before execution and produces a verifiable record either way.

Approach What it does What it misses
Prompt guardrails Hints the model before generation Fragile — bypassable, no decision record
Audit logs Records what happened Too late — action already executed
HITL everywhere Adds manual review steps Fatigue, no policy semantics, no receipts
OAuth / scopes Controls resource access Not action-level authority — no per-action decisions
KiLu Decides before execution. Produces a bounded grant or explicit denial record. Adds an explicit authority layer — you control policy
Reasoning is Not Authority

The authorization gap in autonomous systems

AI systems can propose actions. Policy systems can adjudicate them. But neither step alone creates a bounded execution authority object that can be constrained, linked to an approval event, and verified later.

The result is god-mode agents: systems where planning, policy, authority, execution, and evidence collapse into a single opaque loop. No clear boundary. No verifiable grant. No audit-legible receipt.

The Authorization Gap
  • Approved ≠ authorized. Policy approval does not produce a bounded, scoped, time-limited execution right.
  • Logs ≠ receipts. Execution logs are retrospective and detached. Receipts are cryptographically linked to the authority that permitted the action.
  • Execution rights need scope, TTL, bindings. Without explicit constraints, authority is effectively unlimited.
  • God-mode agents collapse too many roles. Planning, authority, execution, and evidence must be separated — not merged into one opaque process.
How KiLu Works

Authority-to-execution flow

KiLu sits between what a model or ingress surface proposes and what a runtime is permitted to execute. Every step produces an artifact — a grant, a receipt, or a denial record.

Proposal / Ingress — agent or Telegram submits task
Policy / Approval separation — adjudicated outside KiLu
KiLu issues grant — scoped, TTL-bound, approval-linked
Executor receives bounded authority — no grant = no execution
Execution occurs within explicit bounds
Receipt / evidence emitted — linked to grant, verifiable
Verification succeeds — or denial is surfaced as evidence
Grants and Receipts

Two distinct objects. One verifiable chain.

A grant is a bounded execution right, issued after approval. A receipt is the record of what happened under that authority. They are distinct but cryptographically linked.

Grant object
grant_idgrt_a4f8...
subjectapprover:dev_9a2d
action_classweb:fetch
scopeallowlist:klimacoach.com
ttl300s
toolchain_idtc_default_web
approval_siged25519:390a...82f1
Receipt object
receipt_idrec_b7c2...
linked_grantgrt_a4f8...
statusALLOW
timestamp1774280000
intent_hashsha256:a1b2...
tamper_evidenttrue
signatureed25519:9f3a...c1e0

Illustrative structure. Fields represent the object model — not a live receipt from this page. See evidence page →

What KiLu Provides

The authority surface

⬡
Execution Grants
⏱
Scope / TTL / Constraints
🔏
Verifiable Receipts
✕
Deny Evidence
⛓
Split-Trust Model
Use Cases

Three core integration surfaces

🔌
MCP Tool Gating

Wrap tool handlers with a deterministic decision layer. Every tool call passes through ALLOW / REQUIRE_CONFIRM / BLOCK before execution.

View example →
🔗
LangGraph Approval Flows

Use KiLu to decide when actions require confirmation inside a graph. Drive approval flows without changing your graph structure.

View example →
🌐
Browser Action Control

Intercept clicks and form submissions before execution. Works in any browser automation layer — from Playwright to headless agents.

View example →
Where KiLu Fits in the Stack

Three layers. One governed execution chain.

🛡
AegisAI
Decides whether an action is admissible — policy adjudication and governance
aegisai.systems
⬡
KiLu
Issues execution authority and receipts — bounded grants, verifiable evidence
kilu.network
⚙
StasysOS
Runs the bounded execution environment — deterministic, fail-safe runtime
stasysos.eu
Operational Value

What this means for an engineering team

You do not need to redesign your agent stack to introduce authority. KiLu inserts at a single decision point.

Add approval without rewriting your agent stack
Keep reasoning model-agnostic — any LLM, any framework
Record durable decisions — every ALLOW and BLOCK is stored
Separate access, policy, and execution into distinct layers
Reduce unsafe autonomous actions before they happen
Audit what happened long after the fact — from the receipt alone
Verification Posture

Fail-closed by design

Denial is not an error state. It is a designed system behavior. Both the happy path and the deny path produce verifiable artifacts. A denial record is evidence of the system working correctly.

Happy path evidence
  • Grant issued and linked to approval
  • Execution occurs within explicit bounds
  • Receipt emitted with intent hash + signature
  • Verification confirms authority chain
Deny path evidence
  • Missing token → hard deny
  • Expired grant → hard deny
  • Scope mismatch → hard deny
  • Denial artifact recorded as evidence

Read the security and trust model →

FAQ

Common questions

No. KiLu is not a framework and does not replace one. It is an execution authorization layer — a decision point you insert before your existing execution logic. It works alongside MCP, LangGraph, and any browser agent setup.
No. KiLu wraps them at the decision boundary. Your MCP handlers and LangGraph nodes stay exactly as they are. KiLu adds ALLOW / REQUIRE_CONFIRM / BLOCK at the point before execution runs.
No. All examples include a mock authority layer so you can run locally without any backend setup. You can switch to a real control plane path when ready.
REQUIRE_CONFIRM is a decision outcome that tells your system: this action is policy-admissible, but a human (or an upstream approval surface) needs to confirm before it executes. KiLu holds the pending decision and waits for the confirmation signal before issuing a grant.
Yes. The SDK supports both a local mock mode (for development and testing) and a real control plane path. Set KILU_BASE_URL and KILU_API_KEY to point at a running KiLu instance.
Get Started

Start with one execution surface.

Wrap one tool, one browser action, or one approval path.
You do not need to redesign your stack to introduce authority.

Explore the SDK → View Examples