ITISYOU_OS
PRE-ALPHA

System Security &
Authority Model

AI has intelligence, not authority.

01 // THE CENTRAL PRINCIPLE

Any future AI/agent layer reasons about the system and proposes actions; it never executes privileged kernel operations directly. Nothing in the V0.1 runtime contains an AI component — the principle exists now because it constrains interface design: kernel APIs must remain callable only through narrow, deterministic, auditable paths.

// intended pipeline (design, not implemented)

agent intent → policy engine

  → risk/permission evaluation

  → user approval (where required)

  → deterministic privileged service

  → kernel operation → verification

  → audit → rollback/recovery

CONCEPT

Intelligence / authority separation

FUTURE AI / AGENT LAYER

  • − no raw hardware access
  • − no direct kernel calls
  • − proposes, never executes

DETERMINISTIC SYSTEM SIDE

  • + policy & permission evaluation
  • + narrow privileged services
  • + verification, audit, rollback

Kernel APIs are designed so privileged operations can later sit behind this layer rather than being callable by an agent directly.

02 // TRUST BOUNDARIES

  1. BOUNDARY_01 CURRENT

    Firmware/bootloader boundary

    SeaBIOS/OVMF + the rust-osdev bootloader run before the kernel; boot-provided data (memory map, framebuffer, RSDP) is validated before broad use. Boot-time-only code is not part of the OS runtime.

  2. BOUNDARY_02 CURRENT

    Kernel trusted boundary

    All Rust no_std code in kernel/ — the trusted computing base.

  3. BOUNDARY_03 CURRENT

    Userspace boundary

    V0.2, verified for a single process: ring 3 execution with MMU-enforced separation (U/S bit), syscall arguments validated before any kernel dereference, no user mapping of kernel pages, faults contained to the process. Per-process page tables (isolation between user processes) are future work.

  4. BOUNDARY_04 FUTURE

    Privileged system-service boundary

    Future.

  5. BOUNDARY_05 FUTURE

    Untrusted application boundary

    Future.

  6. BOUNDARY_06 FUTURE

    AI/agent boundary

    Future — governed by the authority principle above.

  7. BOUNDARY_07 FUTURE

    External network boundary

    Future — no network stack exists in V0.1.

03 // V0.1 IN PRACTICE

The current security posture is honest about its stage: the kernel runs ring 0 inside QEMU with one Ring 3 process at a time under MMU-enforced separation, and isolation research starts at the boundary definitions, not premature claims. These are the concrete requirements in force now.

  • UNSAFE MINIMIZED

    unsafe localized and documented with invariants; inventory tracked in docs/UNSAFE_INVENTORY.md (SEC-001).

  • PAGE PERMISSIONS

    NX / page-permission separation where the boot path permits; no writable+executable mappings by design once paging is owned by the kernel.

  • PANIC ON VIOLATION

    Panic on violated kernel invariants rather than continuing corrupted.

  • VM CONTAINMENT

    No network services. No host filesystem sharing into the guest. QEMU launches attach only project-generated disposable images (SEC-002).

  • SECRET HYGIENE

    Dependency and secret scans before pushes; secrets never in source, logs, or history.

04 // THREAT MODEL (V0.1 SCOPE)

Scoped to development reality: a pre-alpha kernel running only inside QEMU on the developer’s machine.

V0.1 risks, vectors and mitigations
RiskVectorMitigation
Host damage from OS testing misconfigured VM (disk passthrough, raw device writes) QEMU launches only project-generated images; no passthrough flags anywhere in scripts/harness; physical-hardware boot is out of scope
Kernel bug corrupting its own state silently logic errors, bad unsafe panic-on-invariant-violation; boot-stage markers; selftests; unsafe inventory
Malformed boot data firmware/bootloader handoff anomalies validate memory map/pointers before use; reject overlapping regions
Malformed initramfs corrupt/hostile archive bytes strict bounds-checked parsing with negative-case tests (planned with FS-001)
Supply-chain drift dependencies with unexpected code small pinned dependency set, Cargo.lock committed, rationale per kernel dependency
Secret leakage tokens in commits/logs/CI secret scan before pushes; env-var/platform secret stores only
Fake completion claims without evidence requirement matrix + machine-readable QEMU evidence; website generated from status/current.json

Explicit non-threats for V0.1

Remote attackers (no network stack), malicious local users (single-developer VM), physical attacks, and side channels are out of scope until the relevant subsystems exist. Each later milestone — userspace, storage, networking — must extend the threat model before shipping the feature. The highest-value asset is the developer’s host machine: the OS must never touch it.

05 // FUTURE CAPABILITY MODEL

CONCEPT

subject → capability → object → permitted operation → constraints → provenance

Capabilities explicit, inspectable, revocable, and narrower than blanket administrator privilege. Recorded now — as documented direction, not implementation — so V0.2+ interfaces grow toward it instead of retrofitting.

Full security model Full threat model