kilu.network / Security
Security

Security is a property
of bounded authority

KiLu is not a general cybersecurity system. Its security properties are specific: they concern the integrity of execution authority — how grants are issued, validated, and denied, and what happens when the boundary is violated.

If authority is ambiguous, execution must not proceed.
Ambiguity is not a valid authorization state. Silence is not permission.
Threat Posture

Why fail-open is not a valid operating mode

In a bounded authority model, the default state is no authority. Execution does not proceed unless a valid, in-scope, non-expired grant is present and verified. Any configuration, implementation, or failure mode that allows execution in the absence of a valid grant is a security violation — not a degraded mode.

Fail-Open
Execution without valid authority
A system that executes when no grant is present — or when the grant check fails — has abandoned the authority model entirely. Any action taken under this condition is unauthorized by definition.
Fail-Closed
Deny and emit — no fallback
When a grant is absent, expired, malformed, or out of scope, the Hub emits a denial record and blocks execution. There is no fallback mode, no retry window, and no degraded authorization path.
Config drift
Misconfiguration is an attack surface
The most common class of authorization failures is not external attack — it is configuration that accidentally widens the authority boundary. An empty allowlist must never mean allow-all. A missing TTL must never mean no expiry.
Evidence
Denial produces evidence — silence does not
A correctly functioning system emits a denial artifact when it refuses. A silent failure — where no denial is recorded — is indistinguishable from a fault. The absence of a record is not evidence of correct behavior.
Threat Classes

Known threat classes against execution authority

These are the threat classes that KiLu's architecture is designed to address. Each represents a distinct attack vector against the bounded authority model.

Forged grant
TC·01
An attacker presents a grant that was not issued by the KiLu authority. The Ed25519 signature check at Hub validation will fail. A forged grant produces a hard deny. The authority public key is the verification anchor — it does not change between sessions.
BLOCKED
Replayed grant
TC·02
A previously used, valid grant is presented again. The JTI (single-use nonce) makes a second presentation an unconditional deny. There is no deduplication window — replay is always rejected.
BLOCKED
Expired authority reuse
TC·03
A grant whose TTL has elapsed is presented. TTL enforcement is at the Hub level — the Hub checks expiry at validation time, not at grant issuance time. An expired grant produces a hard deny regardless of signature validity.
BLOCKED
Scope escalation
TC·04
A grant issued for web:fetch on a specific allowlist is presented for a different action or target. The Hub validates scope at the action-class level. Out-of-scope execution is a hard deny.
BLOCKED
Misbound runtime
TC·05
A grant issued for one toolchain_id or runtime binding is presented to a different Hub or toolchain. The Hub checks the toolchain binding explicitly. A grant cannot authorize execution in an environment it was not issued for.
BLOCKED
Forged receipt
TC·06
An attacker presents a receipt that was not issued by the KiLu authority. The Ed25519 signature on the receipt is verifiable against the authority public key. A forged receipt will fail signature verification by any verifier holding the public key.
DETECTABLE
Detached receipt
TC·07
A valid receipt is presented without its linked grant, or with a grant_id that does not match the claimed execution. The linked_grant and intent_hash fields allow cross-reference verification. A detached receipt confirms a different event, not the claimed one.
VERIFIABLE
Fail-open config drift
TC·08
A configuration change widens the authority boundary — an empty allowlist passes all scopes, a missing TTL disables expiry, a misconfigured Hub skips the grant check. This is the highest-probability threat class in production systems. Scope must be explicit; absence of configuration must default to maximum restriction.
OPERATOR RISK
Rejection Taxonomy

What KiLu rejects by design

Rejection is structural — not a runtime policy choice. The following conditions always produce a deny without fallback.

Condition
Result
MISSING_GRANT No grant token present at Hub validation
Hard deny. Denial record emitted. No execution.
EXPIRED_GRANT Grant TTL elapsed before Hub validation
Hard deny. Signature validity is irrelevant after expiry.
INVALID_SIGNATURE Grant signature does not verify against authority public key
Hard deny. Indicates forgery or key mismatch. No execution.
SCOPE_MISMATCH Requested action or target outside grant scope
Hard deny. Grant is valid but does not authorize this specific action.
TOOLCHAIN_MISMATCH Grant toolchain_id does not match the Hub's registered binding
Hard deny. Runtime binding is not interchangeable.
JTI_REPLAY Grant JTI has already been used in a previous execution event
Hard deny. Single-use nonce prevents replay. No retry path.
SUBJECT_MISMATCH Grant subject does not match the presenting agent identity
Hard deny. Grants are non-transferable. No delegation.
Failure Mode Discipline

How failures must behave

A security boundary is only as strong as its failure behavior. The following are the non-negotiable properties of failure in the bounded authority model.

F·01
Deny must be explicit and structured
A denial is not a null response or an error condition — it is a first-class outcome. Every denial must produce a timestamped, tamper-evident denial record. A system that fails silently — without emitting a denial artifact — has lost the ability to prove it functioned correctly.
F·02
Silence is not success
The absence of a receipt is not evidence that nothing happened. It may indicate a failure to emit, a dropped record, or an undetected configuration fault. A correctly operating system always emits — either an ALLOW receipt or a DENY record.
F·03
Default configuration must not widen authority
Any configuration value that is absent, null, or empty must default to the most restrictive interpretation. An empty allowlist is not an allow-all. A missing TTL is not no-expiry. A misconfigured Hub is not a permissive Hub — it is a fault that must block.
F·04
No fallback authorization path
There is no secondary grant mechanism, no emergency override, and no "break-glass" mode that bypasses authority validation. If the grant check fails, execution fails — unconditionally. Fallback modes are fail-open by definition.
F·05
Partial validity is not validity
A grant that is valid in one dimension but fails in another — correct signature but expired TTL, valid scope but replayed JTI — is entirely invalid. Authority checking is not satisficed by partial conditions. All constraints must hold simultaneously for a grant to be valid.
Configuration Class

The real-world misconfiguration class

Production security failures in authorization systems are rarely caused by cryptographic weakness. They are caused by configuration that silently widens the authority boundary. The following patterns represent the specific misconfiguration class that KiLu's design aims to prevent.

Configuration anti-patterns HIGH RISK
→
Empty allowlist treated as allow-all. If no target allowlist is configured, the grant check must fail — not pass. An absent scope constraint is not an unconstrained scope. scope: [] → must produce SCOPE_MISMATCH, not allow-all
→
Missing TTL treated as no expiry. A grant without an explicit TTL must be treated as expired immediately — not as eternal. Indefinite authority is not bounded authority. ttl: null → must produce EXPIRED_GRANT at Hub validation
→
Grant check bypassed during Hub initialization. A Hub that does not perform grant validation — for any reason, including startup race conditions or configuration not yet loaded — must fail closed. The safe default is always: deny until validation is confirmed operational.
→
Toolchain binding left unset in development environments. A grant issued with no toolchain binding is wide by design. If development Hubs accept any toolchain, a grant intended for development can be replayed in a production Hub with a different binding. Toolchain IDs must be explicit in all environments.
Security Scope

What KiLu's security properties do not cover

Not in scope
Process sandboxing
KiLu does not constrain what a Hub can access at the OS level. A Hub may have filesystem, network, and process rights beyond its grant scope. Sandboxing is an operator or runtime concern — see StasysOS.
Not in scope
Transport security
Grant delivery, Hub communication, and token transmission are not secured by KiLu. The authority chain is integrity-protected — but channel confidentiality and authenticity are the deployment environment's responsibility.
Not in scope
Planner or reasoning correctness
KiLu does not verify that the agent's reasoning about the proposed action was sound or that the AVO faithfully represents the approver's intent. These are upstream concerns — see AegisAI.
Not in scope
Hub integrity
A compromised Hub can emit receipts that pass KiLu signature verification. KiLu signs the receipt — it does not attest to Hub integrity. Hub integrity is an operator and deployment security responsibility.
Not in scope
Post-execution effects
Once execution proceeds under a valid grant, KiLu does not track, monitor, or constrain downstream effects. The receipt confirms the event occurred — not that effects were contained.
Not in scope
Policy correctness
Whether the policy that produced an approval event is itself correct — legally, ethically, or operationally — is an AegisAI and operator concern. KiLu sees an approval event, not the policy that generated it.
Continue
Review the trust model or get in contact
Security defines the failure posture. Trust defines the assurance boundary. If you have a deployment question or a threat class we haven't covered, contact us directly.
Contact → ← Trust
← Trust Contact →