Security Model

Security Model

Purpose

This page describes the evolving security model for XAI OS.

Contents

• Capability Model
• Agent Permissions
• Build and Test Sandboxes
• Administration
• Updates and Rollback
• Sandbox Escape Rejection

Capability Model

XAI OS should use capabilities for resources such as cores, memory arenas, NIC queues, model mappings, Git workspaces, build sandboxes, and deployment hooks.

The QEMU core now enforces the first local policy layer for:

• syscall capability checks;
• read-only initramfs descriptor access;
• Git workspace ownership for sync, patch apply, and patch revert;
• build sandbox ownership for build and rollback operations;
• service update and rollback authorization;
• separate administrative capability checks;
• signed update generation replay rejection;
• signed update development-key id validation;
• sandbox path escape rejection;
• credential and private-key material rejection in logs, update strings, patch IDs, and benchmark records.

These checks are still QEMU-stage policy fixtures. They are intended to prove fail-closed integration and telemetry before the production security model is finalized.

Agent Permissions

App agents should be read-only by default. Git write access, build/test access, network access, and deployment access must be explicit.

AI agent code modification is a privileged action. Default mode is review-before-apply. Commit, push, restart, deploy, and rollback permissions are separate capabilities.

Build and Test Sandboxes

Build and test jobs should run in isolated cells or sandboxes. They should not inherit broad access to production data, credentials, or unrelated repositories.

Administration

Administration should be SSH-only. Password login should be disabled by default. Serial access is for early bring-up and recovery.

The QEMU security-hardening gate introduces XAIOS_CAP_ADMIN as a separate administrative capability. Signed updates require both XAIOS_CAP_UPDATE and XAIOS_CAP_ADMIN; a process with update capability alone is still denied.

The QEMU admin-control-plane gate now runs admin commands from the EL0 /bin/service-manager process. The admin surface records an SSH-only, no-password-login policy, inspects service status, persists status exports at /state/services/admin.state, retrieves log metadata, and rejects unsafe remote admin commands outside the allowlist.

Updates and Rollback

Signed updates, patch review, audit logs, and rollback are required for safe code-changing agents.

The QEMU signed-update check uses a strict development-key format:

xaios-update:v1:gen=<monotonic>:sha256=<64 hex>:key=XAIOS-QEMU-DEV-PUBKEY:sig=<64 hex>

The generation must be strictly monotonic. Replayed generations are rejected. The key id must match the QEMU development public key id. This is not a production signing scheme; it exists to exercise parser, policy, denial, replay, key, and telemetry paths until real key management is added.

The QEMU update transaction runtime now persists update records at /state/updates/update.state. Records include the signed update generation, transaction state, target, and rollback label. The QEMU gate proves one failed staged update recovers through boot fallback and one committed update rolls back through the same rollback path.

Sandbox Escape Rejection

QEMU build/test sandbox manifests reject relative paths, .. path components, and duplicate slash escapes before a sandbox can be created. This prevents workspace and artifact paths from escaping their declared roots during the QEMU contract stage.

Secret Rule

Never commit credentials, tokens, private keys, SSH keys, passwords, or benchmark data containing secrets.

Secrets must also be blocked from generated patches, agent logs, benchmark JSON, and outbound network traffic unless explicitly permitted by policy.

Capability Revocation

Capabilities must be revocable. Revocation should drain affected work, stop the AI Cell if needed, release core leases, and preserve audit logs.

Audit Logs

Audit logs should record:

• human request identity where available;
• agent identity;
• files read and written;
• commands run;
• tests and outputs;
• Git commit and remote operations;
• deployment and rollback events;
• capability grants and revocations.

Related Pages

• App Agents
• Risk Register
• Open Decisions