Execution Authorization Layer for AI Systems
Machine actions
need authority.
KiLu issues bounded execution authority and verifiable receipts
for machine actions after policy has been adjudicated elsewhere.
Bounded grants before execution
Receipts after execution
Built for governed machine systems
✓ Authority loop proven
✓ E2E confirmed — 3/3 runs
✓ Linux Hub baseline — R3.1
Android authority · live
kilu-sdk v0.1 · live
Telegram ingress · live
Why KiLu Exists
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
Proven Execution Baseline — 2026-03-23
Core authority loop — validated
KiLu is not a conceptual proposal. The core authority-to-execution loop has been proven
across multiple independent runs, with both the happy path and the deny path behaving as designed.
✓ Live
Operator Ingress
Telegram → task created → plan represented
✓ Live
Biometric Approval
Ed25519 + Android Keystore, non-exportable keys
✓ Live
Grant Issuance
JTI single-use, scope-bound, approval-linked
✓ Confirmed
Bounded Execution
Hub runs under explicit grant — no grant, no execution
✓ R3.1 Alpha
Linux Hub Baseline
Happy path + deny path both proved, fail-closed enforced
✓ 3/3 E2E runs
End-to-End Smoke
Telegram DONE notification — no restarts, no manual edits
Current state: post-core, pre-release packaging. R2 active. R3 tail hardening in progress.
Full architecture →
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
⏱
Scope / TTL / Constraints
Where KiLu Fits in the Stack
Three layers. One governed execution chain.
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 assurance model and trust limits →
Built for governed machine systems
Integrate execution authority
into your system.
For infrastructure teams, governed agent builders, and evaluators who need
explicit execution authority with verifiable receipts.