Security Model

Security Model

Purpose

This page describes the evolving security model for OSAI.

Contents

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

Capability Model

OSAI 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;
• 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.

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:

osai-update:v1:sha256=<64 hex chars>:sig=OSAI-QEMU-DEV-KEY

This is not a production signing scheme. It exists to exercise parser, policy, denial, and telemetry paths until real key management is added.

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