ID
Peer identity
The local Unix socket exposes kernel-provided peer credentials. Privileged decisions do not trust an arbitrary agent name supplied in JSON.
Security & Trust
Intelligence can be autonomous. Authority stays governed.
KINGAI OS treats models and agents as intelligence—not as the trust root. System actions move through peer identity, Agent Registry, capability policy, target-bound approval and constrained execution before touching privileged system resources.
1 · IdentityUnix peer + registered agent
2 · PolicyCapability + target + risk
3 · ApprovalOne-time when required
4 · ExecDCapability-specific execution
P
Fail-closed policy
Unknown capabilities and identities fail closed. Capability rules remain independent from the model that generated the request.
✓
One-time approval
Approval is bound to Agent, Capability, Target Hash and Peer UID, with expiry and one-time consumption to prevent replay.
E
Constrained ExecD
The privileged broker accepts only registered capability handlers. The current native privileged surface is intentionally narrow rather than a generic root shell.
Current verified boundary
What exists now, and what remains a release gate.
D5 already verifies the identity → policy → approval → scheduler → ExecD path. Broader production sandbox profiles are still being earned and are not represented as complete.
Execution Broker tests
Dedicated CI verifies Unix-socket access, capability allowlisting and rejection of malformed service targets before privileged execution.
Full sandbox profiles
Production AppArmor, seccomp, Landlock and resource-control profiles remain a separate hardening track for additional capabilities.
Trust-root operations
Production signing, TUF key custody, boot trust changes and destructive system actions remain protected release or owner-controlled operations.
A/B updates
Move forward without sacrificing the known-good system.
Updates stage into an inactive slot, boot under health supervision and can return to the last confirmed slot when validation fails.
Recovery
Repair is not a bypass.
Recovery is designed for inspection, rollback and boot repair while preserving trust assumptions rather than silently disabling them.
Layered trust
TUF, Secure Boot and release governance solve different problems.
KINGAI keeps update metadata trust, boot-chain trust and release authorization separate so one credential does not become a universal master key.
TUF client
Signed metadata, expiry and pinned-root behaviors are part of the engineering baseline; production repository key operations are still gated.
Secure Boot
VM validation exists independently from production signing-key custody and production hardware support.
Release gates
Stable requires fresh evidence for signing, recovery, supply chain, delivery, hardware and governance—not static marketing badges.
Every powerful action should have a narrow reason to exist.
KINGAI OS is designed to expand capability without expanding implicit authority.