Security Architecture

A capability-based security model, verified from real code.

Project KAI uses a capability-based security model built around default-deny authorization, centralized policy enforcement, revocation, kill switches, rate limiting, auditability, and fail-closed behavior. KAI OS is the real enforcement layer -- every control described here runs inside the KAI OS codebase itself. This page is an evidence and transparency layer on top of that, not a substitute for it. Generated August 11, 2026. Generated from the KAI OS repository during the latest website data-sync run. Not live.

Security Posture

What's actually enforced

Every item below corresponds to real, tested code -- not a policy statement.

Default-deny capability authorization

Centralized security policy, independently re-verified per request

Single controlled-execution chokepoint

Revocation

Global kill switch

Agent-level kill switch

Capability-level kill switch

Rate limiting

Audit events with secret redaction

Fail-closed policy-error handling

Validation-failure handling

Capability Model

11 capabilities declared

A closed vocabulary -- an agent can only ever be granted a capability that exists in this set. Declaring a capability is not the same as activating it; most of the 11 declared here are not granted to anything.

Currently Active

3 of 11 activated

knowledge.search→ knowledge_brainLOW risk

memory.search→ developer_memoryLOW risk

memory.write→ developer_memoryLOW risk

All 3 are LOW risk and require no credential. Each capability listed here is granted individually to one specific agent, only after its own evidence review -- never merely because it's declared. See each row's risk level above; memory.writeis an append-only write to a single internal ledger, not a general filesystem or network capability.

Not Activated

Everything else stays off

Filesystem write / delete
Network access
Credential access
Content publishing
Process execution
Any future capability, before its own evidence review

Trading / financial transactions and Analytics automation are further than "not activated" -- no capability for either exists in the security model at all today.

Test Evidence

17 real test files

Automated test files across the security architecture -- collectively covering the policy engine, kill switches, revocation, rate limiting, audit logging, and every activated capability's real entrypoint path -- counted directly from the KAI OS repository at build time.

Activation Principle

Capabilities are activated individually, for one specific agent, only after an explicit evidence review -- never merely because a capability is declared.

Default denyRevocableKill-switch protectedRate limitedAuditedFail closed

This page describes real, verified controls -- it does not claim the system is unhackable or immune to failure; no honest engineering claim would. Security enforcement happens inside KAI OS, not on this website. This page will be updated as capabilities change.