Core Principle
Cognition and execution must not be the same thing
AI systems can reason about actions. Policy systems can decide whether actions are admissible.
But neither produces a bounded execution authority object — a scoped, signed,
time-limited right to execute, cryptographically linked to the approval that permitted it.
Without that object, execution happens under implicit, unlimited authority. The agent has
effective god-mode: it can plan, decide, and execute in a single closed loop with no
structured checkpoints, no verifiable grants, and no audit-legible receipts.
KiLu does not decide whether an action is admissible. That is AegisAI's role.
KiLu decides whether an authorized approval event can be converted into
an execution grant — and under what constraints.
Four-Role Model
Structural separation of authority
KiLu's architecture assigns four structurally distinct roles. Each has a bounded
responsibility. No role can substitute for another. No role has authority beyond
its defined scope.
Role 01
Proposal / Ingress Surface
Generates proposals or task intent. May be a language model, an ingress bot,
or an operator. Untrusted by default — proposals are never authoritative.
Untrusted
Role 02
Policy / Human Approver
Adjudicates whether an action is admissible and explicitly approves it.
Approval is biometric-bound and non-delegatable. Key remains on device.
Trusted signer
Role 03
KiLu Authority Layer
Converts an approved event into a bounded execution grant. Issues grants
with scope, TTL, toolchain bindings. Issues receipts after execution.
Does not execute.
Authority issuer
Role 04
Constrained Executor (Hub)
Executes only under a valid, in-scope grant. Fails closed on missing,
expired, or mismatched grant. Emits execution evidence after completion.
Fail-closed runtime
Authority Chain
From proposal to verified receipt
Every execution event traces a complete chain: proposal → approval → grant → execution → receipt.
Each step produces an artifact. No step can be skipped. Late verification is possible because
all artifacts are linked and cryptographically traceable.
Ingress
Proposal submitted
An agent, user, or system surface submits a task intent — a structured
description of a desired action. The intent is not yet authorized. It carries no execution right.
intent: { action, target, params }
Approver
Policy adjudication + biometric approval
The intent is presented to the human approver. They review the AVO
(Action Value Object) and explicitly sign approval with a biometric-bound Ed25519 key
held in Android Keystore. Approval cannot be delegated or replayed.
approval_sig: ed25519: { subject, scope, timestamp }
KiLu
Grant issuance
KiLu verifies the approval signature, evaluates the intent against
active policy, and issues a bounded execution grant. The grant contains scope constraints,
a TTL, toolchain binding, and a JTI (single-use token identifier). JTI prevents replay.
grant: { grant_id, scope, ttl, toolchain_id, approval_sig, jti }
Hub
Bounded execution
The Hub validates the grant before executing. If the grant is missing,
expired, or scope-mismatched, execution is hard-denied. The Hub cannot self-authorize. It
executes only within the toolchain and scope specified in the grant.
ALLOW → execute · DENY → fail-closed · no grant → fail-closed
KiLu
Receipt emission
After execution, KiLu issues a cryptographically signed receipt.
The receipt is linked to the grant, contains an intent hash, timestamp, and tamper-evident
flag. A DENY path also produces a denial artifact — structured evidence that the system
correctly refused unauthorized execution.
receipt: { linked_grant, intent_hash, signature, tamper_evident }
Verifier
Late verification
Any principal with the authority public key can verify the receipt
independently — offline, after the fact. Verification confirms the authority chain:
approval → grant → execution → receipt, all linked cryptographically.
verifyReceiptForIntent(intent, receipt, authorityPublicKey)
Authorization Objects
Grant and receipt — two distinct artifacts
A grant is issued before execution. A receipt is issued after. They are structurally different
objects with different purposes, but they are cryptographically linked through the grant identifier.
Grant object — issued before execution
grant_idgrt_a4f8e2...
subjectapprover:dev_9a2d
action_classweb:fetch
scopeallowlist:klimacoach.com
ttl300s
toolchain_idtc_default_web
jtisingle-use nonce
approval_siged25519:390a...82f1
The Hub must present this grant. If missing, expired, or mismatched — hard deny, no execution.
Receipt object — issued after execution
receipt_idrec_b7c2a1...
linked_grantgrt_a4f8e2...
statusALLOW
timestamp1774280000
intent_hashsha256:a1b2c3...
runtime_idrt_b3d6...
tamper_evidenttrue
signatureed25519:9f3a...c1e0
Illustrative structure. Verify with verifyReceiptForIntent() before trusting.
Execution Surfaces
Hub implementations — approved execution environments
A Hub is a constrained executor: it validates grants, executes within bounded scope,
and emits evidence. Any platform running a Hub becomes an authority-constrained execution
environment. Two Hub surfaces are currently proven.
Android Hub
kilu-pocket-agent · R2 device-verified
- Approver: Ed25519 + Android Keystore, non-exportable keys
- Biometric binding: approval key cannot be extracted or replayed
- QR pairing: runtime-bound session between Approver and Hub
- TaskDetailScreen: 4-section evidence view, device-verified 2026-03-23
- Reference implementation for the full authority loop
Linux Hub
R3.1-alpha · proved 2026-03-23
- First non-Android approval-bound execution surface
- Happy path proved: grant → execute → receipt, 3/3 runs
- Deny path proved: missing token → hard deny, no execution
- Fail-closed boundary enforced at the enforcement layer
- Heartbeat / keepalive hardening in R3 tail phase
Bounded Responsibility
What KiLu does and does not do
KiLu's authority is bounded by design. Understanding the scope boundary is essential
for correct integration. KiLu does not replace policy enforcement or execution safety —
it enforces the authority handoff between them.
KiLu does
- Issue bounded execution grants, scoped to action class + toolchain
- Enforce TTL and JTI (single-use, replay-proof)
- Link grants cryptographically to approval events
- Issue signed receipts after execution
- Produce denial artifacts when execution is refused
- Enable late, offline, third-party verification
- Maintain the audit-legible authorization chain
KiLu does not
- Decide whether an action is admissible (that is AegisAI)
- Execute actions — receipt-only, no direct runtime
- Substitute for a secure execution runtime (that is the Hub)
- Constrain an agent that bypasses execution boundaries
- Guarantee correctness of the agent's reasoning or output
- Replace transport or process-level security
Critical: Importing the SDK alone does not constrain an agent that still has
unrestricted shell, network, or file system access. KiLu is effective only when the execution
path is actually routed through Hub-controlled authority boundaries.
Architectural Guarantees
Separation properties
KiLu's architecture provides a set of structural guarantees — properties that hold by design,
not by convention or runtime checking. These are the invariants of the authority model.
-
G1
No execution without grant. A Hub cannot begin execution without presenting a valid, in-scope grant. There is no fallback mode, no default-allow path, no grace period for missing grants.
-
G2
Grant ≠ infinite authority. Every grant is scoped to a specific action class, toolchain, and time window. Execution outside that scope fails regardless of other conditions.
-
G3
Approval cannot be replayed. Each grant carries a JTI (JWT ID) — a single-use nonce. An expired or already-used grant produces a hard deny, not a retry.
-
G4
Denial is evidence. A DENY path produces a structured denial artifact — not silence, not an error code. Denial records are auditable proof that the system correctly refused unauthorized execution.
-
G5
Late verification is always possible. Any verifier with the authority public key can independently confirm the authority chain offline — approval → grant → execution → receipt — without trusting KiLu infrastructure at verification time.
-
G6
Key non-exportability. The Approver's signing key is held in Android Keystore and bound to biometric authentication. It cannot be extracted, delegated, or replayed independently of the hardware.