Assurance Model
A bounded authority layer — not a safety engine
KiLu sits between policy and execution. Its job is narrow by design:
convert an approved event into a bounded execution right, and produce
a verifiable record that the right was used — or correctly denied.
It does not reason about actions. It does not contain agents. It does not
replace runtime isolation. Each layer in the stack has bounded responsibility,
and KiLu's boundary is authority issuance and receipt generation.
Policy layer
AegisAI
Decides whether an action is admissible. Adjudicates proposals against
policy. Does not issue execution rights — it approves or rejects.
Admissibility
Authority layer
KiLu
Converts an approved event into a bounded execution grant. Issues
signed receipts after execution. Enforces scope, TTL, and replay resistance.
Authority issuance
Execution layer
StasysOS
Runs bounded execution under a valid grant. Deterministic, fail-safe
runtime. Does not self-authorize — requires a KiLu grant to proceed.
Execution safety
Guarantees
What KiLu guarantees
These guarantees hold by design — they are structural properties of the authority model,
not runtime assertions. They are verifiable externally.
G·01
Bounded grants
Every execution grant is bounded to a specific action class, toolchain binding, subject identity, and time window (TTL). A grant does not authorize unlimited execution — it authorizes one constrained event.
G·02
Approval linkage
Every grant is cryptographically linked to the biometric-signed approval event that permitted it. The grant contains the approval_sig of the approver's Ed25519 key, held in Android Keystore with biometric binding.
G·03
Replay resistance
Each grant carries a JTI (JWT Token ID) — a single-use nonce. A second attempt to use an expired or already-used grant produces a hard deny. There is no retry, no grace period, no fallback authorization path.
G·04
Receipt linkage
Every receipt is cryptographically linked to the grant that authorized the execution. The linked_grant field and intent_hash together confirm that the receipt covers the specific authorized action — not any action under that grant.
G·05
Late verification
Any verifier with the authority public key can confirm the full authority chain offline — approval → grant → execution → receipt — without contacting KiLu infrastructure at verification time. The chain is self-contained.
G·06
Denial as first-class behavior
When a grant is missing, expired, or out of scope, the system does not fail silently. It produces a structured denial artifact — a timestamped, tamper-evident record that the system correctly refused execution. Denial is evidence, not an absence of evidence.
Enforcement Boundaries
What KiLu actively bounds
KiLu's enforcement is specific. Each constraint is checked at grant issuance and
at Hub validation — not aspirationally, but structurally.
Action scope
The grant is issued for a specific action class (e.g., web:fetch) and an explicit target allowlist. Execution outside that class or target is a hard deny.
TTL
Every grant has an explicit time-to-live. After expiry, the grant produces no execution right. The Hub enforces TTL — there is no override path.
Toolchain binding
The grant specifies a toolchain_id. The Hub must match this binding. A grant issued for one toolchain cannot authorize execution on a different one.
Subject identity
The grant is bound to a specific approver subject. It cannot be transferred, delegated, or presented by a different identity.
Single-use JTI
The JTI nonce makes each grant a one-time token. Replay — presenting the same grant twice — produces a deny. There is no deduplication window or retry allowance.
Signing key locality
The approver key is held in Android Keystore with biometric binding. It cannot be exported, copied, or used without physical biometric authentication on the registered device.
Outside KiLu
What KiLu does not control
KiLu's authority boundary is explicit. The following are structural responsibilities
that KiLu does not fulfill — by design, not by omission.
Not KiLu
Policy adjudication
Whether an action is admissible — ethically, legally, or operationally — is decided upstream of KiLu. KiLu only sees that an approval event occurred. It does not know why the action was approved.
→ AegisAI
Not KiLu
Runtime isolation
KiLu does not constrain process-level, network-level, or filesystem-level access. A Hub that has been granted a web:fetch scope may still have broader OS access — KiLu does not restrict that.
→ StasysOS / operator
Not KiLu
Reasoning correctness
KiLu does not verify that the agent's reasoning about the action was sound. A receipt confirms an execution event occurred — not that the agent understood the action correctly.
Operator responsibility
Not KiLu
Transport and process security
KiLu does not secure the channel between components. Grant delivery, Hub communication, and logging infrastructure must be secured by the deployment environment.
Operator responsibility
Not KiLu
Planner or agent correctness
KiLu assumes the proposal is submitted in good faith. It does not verify that the agent's intent accurately represents what the approver understood. That mapping is the responsibility of the AVO construction layer.
→ AegisAI / operator
Not KiLu
Downstream effect containment
A receipt confirms an authorized execution — it does not guarantee the downstream effects were contained. If execution modified external state, KiLu does not track or limit those effects beyond the grant's scope.
Operator responsibility
Ecosystem Relationship
How KiLu relates to adjacent layers
Each layer in the governed execution stack has a bounded responsibility.
Trust in the system derives from the combination of all three layers — not from any one layer in isolation.
Policy adjudication and governance. Evaluates whether a proposed action is admissible given the active policy context, approver identity, and operational constraints. Produces an approval event when the action passes. Does not issue execution rights directly.
Admissibility
Execution authority and receipt generation. Receives the approval event, verifies the approver signature, and issues a bounded grant scoped to a specific action, toolchain, and time window. Issues a signed receipt after execution completes. Enforces deny on missing or invalid grants.
Authority
Bounded execution runtime. Executes only under a valid, in-scope KiLu grant. Deterministic, fail-safe kernel designed for autonomous system execution. Does not self-authorize — fail-closed on missing or invalid grant.
Execution
Limits of Interpretation
What a receipt, an SDK, or adjacent tools do not mean
Hard limit
A receipt is not a guarantee of universal safety
A receipt confirms that an authorized execution event occurred under defined conditions. It does not certify that the action was safe, correct, or free of unintended side effects. The receipt boundary ends at the grant scope.
Hard limit
Importing the SDK does not enforce authority
KiLu's authority boundary is only enforced when execution is actually routed through Hub-controlled grant validation. An agent that bypasses the Hub has unrestricted execution, regardless of SDK presence. The SDK enforces nothing by itself.
Hard limit
Adjacent tools are not trusted by default
AegisAI and StasysOS are separate systems with separate trust models. KiLu does not inherit their guarantees, and they do not inherit KiLu's. Each system must be evaluated independently. Trust in the stack requires all three layers to function correctly.
Context limit
KiLu's guarantees hold within its scope — not beyond it
The authority chain is provable within the KiLu boundary: from approval event through to receipt. Actions, effects, or states that occur outside that boundary — in the agent planner, the network, or the external environment — are outside the evidence trail.
Context limit
Hub integrity is assumed — it is not verified by KiLu
A compromised Hub can emit false receipts that pass signature verification, because the receipt is signed by KiLu, not the Hub. Hub integrity is an operator responsibility. This is a
known and documented limit — see
Security.
Next steps
Understand the threat posture
Trust defines assurance boundaries. Security documents threat classes,
failure modes, and what KiLu cannot protect against.